Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-050

Text File | 1995-12-31 | 129.5 KB | 3,199 lines | [TEXT/R*ch]

Received-Date: Wed, 10 Aug 1994 13:16:55 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-050
To: [e-mail]
Date: Wed, 10 Aug 1994 13:16:49 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 55

C.S.M.P. Digest             Wed, 10 Aug 94       Volume 3 : Issue 50

Today's Topics:

        Detecting Apple Events on launch?
        Dialogs and fonts...
        Filtering Edit Text items
        MoreFiles 1.2 available on ftp.apple.com
        Styled Text in Dialogs
        The shock of the new (mac vs unix)
        What does "reentrant" mean?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Chris Severtson)
Subject: Detecting Apple Events on launch?
Date: Wed, 20 Jul 1994 13:44:09 GMT
Organization: Microware Systems Corp., Des Moines, Iowa


I have just added support for the core apple events to a hobby
application of mine and they work great!  I am concerned, however,
about detecting apple events upon application launch.  When my
application is launched, it creates an untitled document window, and
if the application was launched because someone double-clicked one of
its documents in the finder, then I do not want the application to
create this untitled document.

I tried using EventAvail(highLEvelEventMask, evtPtr) before entering
my main event loop to detect this, but it always tells me there are no
pending high-level events.

Is there a better way to detect if you were launched because a user
double-clicked one of your documents in the Finder? (I want to detect
this before I enter my main event loop).


All help is greatly appreciated,

Chris
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 20 Jul 1994 09:35:10 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail]
(Chris Severtson) wrote:

> I have just added support for the core apple events to a hobby
> application of mine and they work great!  I am concerned, however,
> about detecting apple events upon application launch.  When my
> application is launched, it creates an untitled document window, and
> if the application was launched because someone double-clicked one of
> its documents in the finder, then I do not want the application to
> create this untitled document.
>
> I tried using EventAvail(highLEvelEventMask, evtPtr) before entering
> my main event loop to detect this, but it always tells me there are no
> pending high-level events.
>
> Is there a better way to detect if you were launched because a user
> double-clicked one of your documents in the Finder? (I want to detect
> this before I enter my main event loop).

This is pretty well spelled out in Inside Mac: Interapplication Communication.

Briefly:  if Apple events are not implemented (ie, you still support
archiac pre-7 Systems), do the old thing with the application parameters.

If Apple events ARE implemented, when your program is launched just do
your no-matter-what initialization.  Shortly, you will receive one of:
   'aevt'/'oapp'   meaning:  your app was double-clicked on (or you should
act that way)
   'aevt'/'odoc'   meaning:  the user wants you to open these documents
   'aevt'/'pdoc'   meaning:  the user wants you to print these documents,
bugging him/her as little as possible

You'll only get one of these as the aftermath of being launched.  That's
how you decide whether to open an untitled document.  [You can receive
'odoc' and 'pdoc' later, too.]

If Finder wants you to quit after printing as the result of a 'pdoc', it
will send an 'aevt'/'quit' event.  It does that if your app was not
running when the user asked Finder to print the document.
   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   No hablo Intel.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (JohnC)
Date: Thu, 21 Jul 1994 05:17:15 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Chris Severtson) writes:
>I have just added support for the core apple events to a hobby
>application of mine and they work great!

Cool.  Did you do it by installing event handlers via the Apple Event
Manager?

>I am concerned, however, about detecting apple events upon application
>launch.
>
>Is there a better way to detect if you were launched because a user
>double-clicked one of your documents in the Finder? (I want to detect
>this before I enter my main event loop).

WHY do you want to do it before the main event loop?  Why not do it as Apple
intended:  -Initialize (installing your Apple Event handlers)
           -Start your even loop
           -pass each high-level event to AEProcessAppleEvent

If the Finder launches you, you are guaranteed to get EITHER an
OpenDocuments event OR an OpenApplication event, NOT both.  Your
OpenApplication handler puts up an untitled window, whereas your
OpenDocuments handler opens the specified document or documents but does
not put up an untitled window. Your QuitApplication handler sets a flag that
will cause your event loop to terminate.  Your PrintDocuments handler will
print the specified document or documents.  It really is just about that
simple.  There is some clear sample code in either IM-6 or
IM-Interapplication Communication.


--
  ______     John Cavallino - B0 f++ w c+ g++ k+ s++ e h- pv
  \    /     queer person
   \  /      EMail: [e-mail]
    \/       It should absurdly obvious that I speak ONLY for myself.

+++++++++++++++++++++++++++

>From [e-mail] (Owen Mathews)
Date: 21 Jul 1994 15:02:56 GMT
Organization: furman university computing center

Chris Severtson ([e-mail]) wrote:

: I have just added support for the core apple events to a hobby
: application of mine and they work great!  I am concerned, however,
: about detecting apple events upon application launch.  When my
: application is launched, it creates an untitled document window, and
: if the application was launched because someone double-clicked one of
: its documents in the finder, then I do not want the application to
: create this untitled document.

: I tried using EventAvail(highLEvelEventMask, evtPtr) before entering
: my main event loop to detect this, but it always tells me there are no
: pending high-level events.

: Is there a better way to detect if you were launched because a user
: double-clicked one of your documents in the Finder? (I want to detect
: this before I enter my main event loop).


: All help is greatly appreciated,

: Chris
: [e-mail]

Actually, I think it's even simpler than that...

The system should *automatically* put an apple event in the event queue when
your application is opened (see previous post); all you should need to do
is go straight to your event loop.  The first event you get with
WaitNextEvent() should be the AppleEvent you need to determine whether or
not the user has double-clicked on a file belonging to you application.
EventAvail() before your loop should also work.

IOW, what you posted above *should* work (as far as I know :) ).  The
only reason I can think of why your code does not work is the flags in
the SIZE resource.  Unless you make sure to set the IsHighLevelEventAware
flag, the system won't send you any AppleEvents when it launches your
app.  Set the flag either by making your own SIZE resource with ResEdit,
or by selecting the appropriate option when building your application.

Hope this sheds a little light...   :)

--
       Owen Mathews    [e-mail]
       <><><><><><><><><><><><><><><><><><><><>
       Furman University, Computer Science Dept

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Thu, 21 Jul 1994 18:40:04 GMT
Organization: ISIS International

[e-mail] (Chris Severtson) writes:

When you start up, *don't* create an untitled document; just do the rest of
your initialization and enter your main event loop.Next, you'll receive either
an 'odoc' event if a document was double-clicked or an 'oapp' if only the
application was double-clicked. You should create a new document when you
receive the 'oapp' event. Currently, there will only be one 'oapp' when the
application is started with no documents, but in the future you may receive
them when an already running application is double-clicked in the Finder.

>I have just added support for the core apple events to a hobby
>application of mine and they work great!  I am concerned, however,
>about detecting apple events upon application launch.  When my
>application is launched, it creates an untitled document window, and
>if the application was launched because someone double-clicked one of
>its documents in the finder, then I do not want the application to
>create this untitled document.

>I tried using EventAvail(highLEvelEventMask, evtPtr) before entering
>my main event loop to detect this, but it always tells me there are no
>pending high-level events.

>Is there a better way to detect if you were launched because a user
>double-clicked one of your documents in the Finder? (I want to detect
>this before I enter my main event loop).


>All help is greatly appreciated,

>Chris
>[e-mail]

--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: file://ftp.netcom.com/pub/isis/home.html

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: 26 Jul 1994 17:30:02 GMT
Organization: Integer Poet Software

In article <[e-mail]>
[e-mail] (JohnC) writes:

> >Is there a better way to detect if you were launched because a user
> >double-clicked one of your documents in the Finder? (I want to detect
> >this before I enter my main event loop).
>
> WHY do you want to do it before the main event loop?  Why not do it as Apple
> intended:  -Initialize (installing your Apple Event handlers)
>            -Start your even loop
>            -pass each high-level event to AEProcessAppleEvent

Because this AE handling model assumes a traditional document-oriented
app. If your app is not such a thing, there may be a decent reason for
you to wait and see whether you are going to get an open-application or
open-documents or print-documents event. I just did it in a Eudora
add-on app I'm writing. I wrote another event loop which calls
WaitNextEvent with a mask which exlcudes everything but AppleEvents.

--

Pete Gontier // Integer Poet Software // [e-mail]

"Clear-cutting removes all trees... to create new habitats for
wildlife. P&G uses this economically and environmentally sound method
because it most closely mimics nature's own processes. Clear-cutting
also opens the floor to sunshine, thus stimulating growth and providing
food for animals."

    -- Procter & Gamble's "Decision Earth" free school curriculum

---------------------------

>From Tony Andreoli <Tony_Andreoli_-_CTA@CL_C21SMTP_GW.CHINALAKE.NAVY.MIL>
Subject: Dialogs and fonts...
Date: Sat, 23 Jul 1994 14:00:17 GMT
Organization: Naval Air Warfare Center - Weapons Division

I have a dialog that contains a series of editText and staticText fields,
the problem is, I want them to be in Geneva 9!  I understand that
SetDAFont will allow me to adjust the font, but how to I set the point
size (as TextFont and TextSize don't work)?  Think Reference say's
there's no "direct" method, but what about an indirect one?

Thanks...
Tony Andreoli

+++++++++++++++++++++++++++

>From [e-mail] (Jasna M. Arezina-Wilson)
Date: Tue, 26 Jul 1994 17:49:55 -0400
Organization: Ohio State University

In article <[e-mail]>, Tony Andreoli
<Tony_Andreoli_-_CTA@CL_C21SMTP_GW.CHINALAKE.NAVY.MIL> wrote:

> I have a dialog that contains a series of editText and staticText fields,
> the problem is, I want them to be in Geneva 9!  I understand that
> SetDAFont will allow me to adjust the font, but how to I set the point
> size (as TextFont and TextSize don't work)?  Think Reference say's
> there's no "direct" method, but what about an indirect one?

Try this for a function (in C):

void SetDialogFontAndSize(DialogPtr theDialog, short fontNum, short
fontSize)
{
    FontInfo    f;

    SetPort(theDialog);

    // set up the port info
    TextFont(fontNum);
    TextSize(fontSize);

    // now deal with the static & edit text issues
    GetFontInfo(&f);
    (*((DialogPeek)theDialog)->textH)->txFont = applFont;
    (*((DialogPeek)theDialog)->textH)->txSize = 9;
    (*((DialogPeek)theDialog)->textH)->lineHeight =
                 f.ascent + f.descent + f.leading;
    (*((DialogPeek)theDialog)->textH)->fontAscent = f.ascent;
}


However, this will not do it for for buttons, but it will do it for Static
and Edit text fields. Anyone know how to do it for buttons without changing
the system font (since this has the side effect of wrecking the menu font).


- ----------------------------------------
"...when friends rejoice both far and near
 How can I keep from singing?" - Enya

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: Wed, 27 Jul 94 14:50:58 GMT
Organization: UCLA, Computer Science Department

In article <[e-mail]> [e-mail] (Jasna M. Arezina-Wilson) writes:
>In article <[e-mail]>, Tony Andreoli
><Tony_Andreoli_-_CTA@CL_C21SMTP_GW.CHINALAKE.NAVY.MIL> wrote:
>
>> I have a dialog that contains a series of editText and staticText fields,
>> the problem is, I want them to be in Geneva 9!  I understand that
>> SetDAFont will allow me to adjust the font, but how to I set the point
>> size (as TextFont and TextSize don't work)?  Think Reference say's
>> there's no "direct" method, but what about an indirect one?

[Code Deleted...]

>However, this will not do it for for buttons, but it will do it for Static
>and Edit text fields. Anyone know how to do it for buttons without changing
>the system font (since this has the side effect of wrecking the menu font).

To force controls to use their window's font, simply add the constant useWFont
(or something like that; refer to IM: Mac TB Essentials, "Control Manager"
chapter) to the variation code of the control. No need to change the system
font.

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
Death to the Trojans! Go Bruins!

(Insert disclaimer here)
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jasna M. Arezina-Wilson)
Date: Wed, 27 Jul 1994 13:12:26 -0400
Organization: Ohio State University

In article <[e-mail]>, [e-mail]
(Christopher Larson) wrote:

> To force controls to use their window's font, simply add the constant useWFont
> (or something like that; refer to IM: Mac TB Essentials, "Control Manager"
> chapter) to the variation code of the control. No need to change the system
> font.

Okay, how does one do that without building the DITL on the fly? I read
that you can patch the GetNewControl (or NewControl, depending on what your
computer is doing) and modify that as it goes by, but I haven't been able
to come up with a working patching function (one that just falls-through,
that is).

(BTW, IM:MTBE isn't avail to me)


- ----------------------------------------
"...when friends rejoice both far and near
 How can I keep from singing?" - Enya

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 27 Jul 1994 20:16:05 GMT
Organization: Apple Computer

Jasna M. Arezina-Wilson, [e-mail] writes:
> Okay, how does one do that without building the DITL on the fly?

You can use control items -- with associated CNTL resources -- instead of
buttons. Keeping the resources in sync is a bit of a pain, but the CNTL does
let you specify the variation code.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (JamesW7955)
Date: 27 Jul 1994 19:49:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, Tony Andreoli
<Tony_Andreoli_-_CTA@CL_C21SMTP_GW.CHINALAKE.NAVY.MIL> writes:

>> I have a dialog that contains a series of editText and staticText
>>fields,
>>the problem is, I want them to be in Geneva 9!  I understand that
>>SetDAFont will allow me to adjust the font, but how to I set the >>point
>>size (as TextFont and TextSize don't work)?  Think Reference say's
>>there's no "direct" method, but what about an indirect one?

Have you looked at the 'ictb' resource? It allows you to specifiy fonts
for items in a DITL (as well as colors and other goodies). It is
documented in IM: Mac toolbox essentials. Beware: it is a tough resource
to build and its structure may leave you scratching your head.

- James Wilson
[e-mail]

---------------------------

>From [e-mail] (Al Spohn)
Subject: Filtering Edit Text items
Date: 26 Jul 1994 04:01:57 GMT
Organization: Mayo Clinic

I've working on a dialog box that takes a time, e.g., 23:12:14.35 as
user input.  The input is organized into four edit text boxes - hours,
minutes, seconds, and hundredths.

Before I pose my question, I should let you know that I ordered the
"Text" volume of Inside Macintosh - it just hasn't arrived yet.  So, if
the answer to my question is in-depth and covered in that book, feel
free to blow this off.  However, on the off chance that there's a
relatively quick, easy answer, I'll go ahead and pose the question:

What's the best way to restrict the input of each of the text edit
boxes to two digits?  I've played with a few different ideas, but I
continue to be plagued by the funky scrolling that ensues when the user
enters more than two digits.  I don't want to be too much of a nazi in
the way I restrict the input, i.e., I'd prefer to be within sight of
Apple's user interface guidelines.  If I could count on the user tabing
to each field and just replacing highlighted text, things would be
easy.  It's dealing with the insertion point and what happens to the
text as a result that has me stumped.

Any suggestions would be appreciated!

**********************************************************************
*  Al Spohn   [e-mail]  507-284-1666 Mayo Clinic  Hilton 517A  *
**********************************************************************

+++++++++++++++++++++++++++

>From [e-mail] (Doug Williams)
Date: 26 Jul 1994 14:05:45 GMT
Organization: University of Arizona, Tucson, AZ

In article <3121rl$[e-mail]> [e-mail] (Al Spohn) writes:
>What's the best way to restrict the input of each of the text edit
>boxes to two digits?  I've played with a few different ideas, but I
>Any suggestions would be appreciated!


Get DialogBits from ftp.apple.com.  It has working source code to
handle exactly what you are asking for (limiting the number of
characters in an edit box), and also show how to limit the input to
only digits.  There are a few mistakes in it (< instead of <=), but
they are pretty obvious.

-=-doug-=-



+++++++++++++++++++++++++++

>From [e-mail] (mark tillinghast)
Date: 26 Jul 1994 07:53:49 -0000
Organization: Los Angeles Macintosh Group BBS

Al Spohn,[e-mail],Internet writes:
>I've working on a dialog box that takes a time, e.g., 23:12:14.35 as
>user input.  The input is organized into four edit text boxes - hours,
>minutes, seconds, and hundredths.


>What's the best way to restrict the input of each of the text edit
>boxes to two digits?  I've played with a few different ideas, but I
>continue to be plagued by the funky scrolling that ensues when the user
>enters more than two digits.  I don't want to be too much of a nazi in
>the way I restrict the input, i.e., I'd prefer to be within sight of
>Apple's user interface guidelines.  If I could count on the user tabing
>to each field and just replacing highlighted text, things would be
>easy.  It's dealing with the insertion point and what happens to the
>text as a result that has me stumped.


 One way is to create a filter-proc for your dialog. That way you can
conviently restrict it to two digits, error trap bad times, (ie 25.61.61.00).
The filterproc essentially gives you first dibs on the Next event.
  You need somthing more than Inside Macintosh if you are going to use the C
programming language. Inside Macintosh describes things in terms of the
pascal programming language, and the translation to the C programming
language is, in the case of the filterproc, inobvious.
  It is precisely because Inside Macintosh is in pascal that I recommend
"Macintosh Programming Secrets" by Scott Knaster and Keith Rollins  2nd
Edition Addison Wesley 1992. Chapter 4 of this book deals with dialogs modal
and modeless.

I have done this filter proc thing before, but if you want to know what I
think is a slick way to do it, take a look at the alarm clock DA.  If you
make your program behave like the alarm clock DA, I think it will be easy to
use.

Have fun!


---------------------------

>From [e-mail] (Jump Long)
Subject: MoreFiles 1.2 available on ftp.apple.com
Date: 27 Jul 1994 11:52:08 -0400
Organization: America Online, Inc. (1-800-827-6364)

Yesterday I finished MoreFiles 1.2.  I've added lots of new code, and
enhanced several of the existing routines. The change history for version
1.2 is pasted below.

MoreFile 1.2 is available now at:

    ftp.apple.com (IP address 130.43.2.3)

    /ftp/dts/mac/sc/more-files-1-2.hqx

Thanks to all of you who have reported bugs, or suggested enhancements and
additions.

- Jim Luther, Apple Developer Technical Support

- --------------------------------------
v1.2  07/20/94

New Routines:
-  Added GetDInfo, FSpGetDInfo, SetDInfo, FSpSetDInfo, CheckVolLock,
CheckObjectLock, and FSpCheckObjectLock to MoreFilesExtras.
-  Added MoreDesktopMgr. In the process, I moved GetComment, SetComment,
and CopyComment over from MoreFilesExtras and changed their names (added a
DT).  My apologies to anyone this API change screws up. I think the new
and improved code makes up for the hassles.
-  Added Search. Ever want to search a volume with PBCatSearch and it
isn't available? Then you'll like this code.

Enhancements to existing routines:
-  Made changes for powerc.
-  THINK C project is for version 7.0.3.
-  Reformatted code to meet new DTS standards for sample code.
-  Added code to FileCopy to open and copy only file forks that contain
data. By doing this, we won't create a data or resource fork for the
copied file unless it's really needed (some foreign file systems such as
the ProDOS File System and Macintosh PC Exchange have to create additional
disk structures to support resource forks).
-  Added code to FileCopy to copy the file attributes to the destination
only if the destination is an AppleShare drop box. That way, if the file
has the bundle bit set and if FileCopy is modified (by you - read the
comments in the source before modification) to give up time to other
processes during a copy, any Finder with access to the file won't try to
read bundle information from a partially copied resource fork.
-  DirectoryCopy no longer calls your CopyErrProc with a copyDirCommentOp
failed operation code. There's really nothing wrong with comments not
getting copied and DirectoryCopy does give it its best effort.
-  Modified OpenAware and OpenRFAware functions to check for locked volume
if write access is requested.
-  Rewrote GetObjectLocation so that it calls PBGetCatInfo fewer times
(worst case is two calls). That makes the code a little harder to read,
but on slow volumes (for example, AppleShare volumes over AppleTalk Remote
Access), fewer calls *is* better.
-  Replaced the static pcpy functions with calls to BlockMoveData (which
is BlockMove if you don't have System Update 3.0, System 7.5, or later).
-  The routines in MoreDesktopMgr (used to be in MoreFilesExtras) can get
APPL mappings, icons, and comments from the "Desktop" file if the Desktop
Manager isn't supported by a volume.
-  NameFileSearch and CreatorTypeFileSearch in MoreFilesExtras now call
PBCatSearchSyncCompat in Search so that they can search on all volumes.
-  Tweaked all headers so that they can be read by a future "documentation
viewer" project.

Bugs fixed:
-  Changed DTCopyComment to use Str255 instead of unsigned char
commentBuffer[199]. PhotoCD's wrongly return up to 255 characters instead
of 200 characters and that was trashing memory.
-  Changed FSMakeFSSpecCompat to fix Macintosh PC Exchange 1.0.x bug.
-  Fixed a couple of bugs in GetFilenameFromPathname.
-  Fixed ChangeFDFlags and ChangeCreatorType to get the real vRefNum
before calling BumpDate. BumpDate was "bumping" the wrong object in some
cases.
-  Fixed GetParentID so that it gets the right parent ID in all cases (HFS
has a weird bug that I work around).
-  Cleared ioFVersNum field for all PBHOpenDF, PBHOpenRF, PBHOpen,
PBHCreate, PBHDelete, PBHGetFInfo, PBHSetFInfo, PBHSetFLock, PBHRstFLock,
and PBHRename calls. Not needed for HFS volumes, but some of those old MFS
volumes might still be around.
-  Changed the macro name hasLocalList to hasLocalWList to match bit name
in Files.h.

end.

---------------------------

>From [e-mail] (Rogers)
Subject: Styled Text in Dialogs
Date: 25 Jul 1994 21:44:07 GMT
Organization: The MITRE Corporation, Bedford, MA

Can anyone tell me how to change the font, size, and style of
the text for dialog items, including buttons?

Thanks,
         Jeff Rogers
         The MITRE Corp.


+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 26 Jul 1994 20:27:41 GMT
Organization: Apple Computer

Rogers, [e-mail] writes:
> Can anyone tell me how to change the font, size, and style of
> the text for dialog items, including buttons?

You can change the text style of static and edit-text items by changing the
style of the grafPort (via TextFont, TextSize, TextFace). You also need to
update the txFont, txSize, txFace fields of the dialog's TE record, then call
TECalText. Don't forget to SetPort to the dialog first. It looks better if
you turn off the isVisible flag in the DLOG resource, then manually call
ShowWindow after making your changes.

Changing the style of buttons is harder. If you create the button yourself
using NewControl, you can OR the variation code with 8 (useWFont) which will
make the title of the button appear in the grafPort's current font.
Unfortunately control items in dialogs are created for you by the dlog mgr
and there is no way to change their var code once created.
The two ways I know of to get around this are:
(A) make all your buttons be control items, not buttons, then set the
variation code in the CNTL resource
(B) Temporarily patch out GetNewControl during the call to GetNewDialog. In
the patch, OR the varCode with useWFont and call through to the old trap.
(This is what I do in Stickies and it works great.)

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Jasna M. Arezina-Wilson)
Date: 27 Jul 1994 11:14:49 GMT
Organization: Ohio State University

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:


> (B) Temporarily patch out GetNewControl during the call to GetNewDialog. In
> the patch, OR the varCode with useWFont and call through to the old trap.
> (This is what I do in Stickies and it works great.)

Are you this this is right? I tried it, and GetNewControl is not called -
NewControl is. (at least on my SE & sys7.0) Could you post your code
fragment here or to alt.sources.mac?

- ----------------------------------------
"...when friends rejoice both far and near
 How can I keep from singing?" - Enya

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 27 Jul 1994 20:08:54 GMT
Organization: Apple Computer

Jasna M. Arezina-Wilson, [e-mail] writes:
> Are you this this is right? I tried it, and GetNewControl is not called -
> NewControl is. (at least on my SE & sys7.0)

Oops, you're right. It's NewControl you need to patch.

> Could you post your code
> fragment here or to alt.sources.mac?

Unfortunately the code I have that does this is part of Stickies, and Apple
wouldn't want me to redistribute the source. I should probably snip out just
the essentials and give them to DTS as an official Snippet...

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

---------------------------

>From [e-mail] (Laurence R. Brothers)
Subject: The shock of the new (mac vs unix)
Date: Thu, 21 Jul 1994 17:27:17 GMT
Organization: Bellcore


I don't intend to start a flame war about relative merits of things
with this article, but I must say that as a programmer familiar with a
variety of unix gui toolkits, ranging (historically) from Sunview all
the way through TCL/TK, that my introduction to the Mac environment
was rather a shock.

Keep in mind I'm used to an environment where you just don't have to
worry about managing and dispatching your own events, and even
updating windows will often be magically taken care of for you.  Most
unix GUI toolkit objects either have useable default behavior, or you
simply register callbacks for them. You never have to mess with the
event loop in a typical X application unless you're doing something
really weird and/or low-level. In fact if you use TCL/TK (that's a
different TCL than the Mac acronym, by the way), almost every little
thing is taken care of with amazingly acceptable default behaviour in
the toolkit library.

A list of amazements as I started trying to develop some simple test
applications to learn the Mac development environment:

* What, I have to write my own event loop? Haven't they heard of
callbacks?  Interposition? Well, I guess it's not a pre-emptive OS,
but still, does that make any difference?

* I have to manage operating system events myself? What's the point of
having an operating system if it can't manage its own events?

* I have to write an event procedure in case someone inserts an
unformatted disk? Give me a break. How about I request a notification
only if I'm interested in a bad disk event, and otherwise you take
care of it, Mr. Disk Manager? No deal? Too bad.

* OK, first I see the event is in the menu bar, then I adjust the
menus to show what is active, then I call the menu tracking procedure,
then I divide a long int into two "words" (gee, 16 bit words, I wonder
where that came from -- me, I call it a half-word.... :-), then I find
out which menu and item it was, then I get to actually have my own
code do something after checking the global state of the program.  How
baroque.

* Wait a minute, this isn't a scrollbar, it's just a bit of graphics.
It doesn't actually *do* anything. It takes a page of code just to get
to the point that you find out which scrollbar thingie got clicked on,
then you have to do it all yourself. Apple wouldn't have to have all
this style guide stuff if they actually implemented any functionality
anywhere.

* Hmm... I guess the zoom box and the grow icon don't do anything
either. Well, gee, at least I have system zoom and grow procedures,
but my event procedure needs at least a page of checks surrounding
each one before I can call it. Same thing for window movement.

* Hey wait a second, you mean I actually have to activate and
deactivate the windows myself? I have to deselect the controls, and
all that? Oh come on....

* I guess geometry management is too much to ask for? Oh well. Should
have known better than to ask. Of course there are no subwindows on
the Mac anyhow, so I guess there's not much point.

* Oh well, at least the update event is the same. What, you say I
shouldn't use backing store? Why not? Why provide the feature and then
say not to use it?

                ...


Well, you can see what I mean, if you have any familiarity with your
typical Unix/X toolkit (which I had previously thought of as the
pessimal programming environment!)

I have to qualify all this by saying I've only been messing around
with Mac programming for a few weeks, so I am not used to it all yet,
but still.... I would have thought the basic programming paradigm
might have advanced slightly in the last 10 years, at least to the
extent of a standard re-entrant toolkit event-loop with callbacks and
event interposition instead of all this manual dispatching. Even in an
antique like Sunview you could code a typical application in probably
1/5 to 1/2 the space of an equivalent Mac application.

It must take at least 500 lines of C to produce a Mac application that
is minimally conformant to the general rules of application behavior,
probably more. IMHO, even a 3 line hello world program should
automagically do all "the right things" because the windowing
environment/finder/OS/whatever should take care of it all.

I also must admit that I have only been using MPW C, not MacApp or any
of the C++ stuff as yet. I imagine that every Mac programmer must use
some standard application framework to build their programs after a
while, be it MacApp, AppWannaBe, or whatever, but still, the whole
thing seems a lot more awkward than it really needs to be.

Of course all the above is IMHO only.... Of course there are many
things available on the Mac platform that are either real expensive or
very hard to implement in the typical unix environment. Still, I would
really like someone to tell me: "You obviously haven't used the foo
class libraries with the bar uims package and the baz event manager
yet, so what do you expect".
--
             Laurence R. Brothers ([e-mail])
  Bellcore -- Computing Technology Integration -- Knowledge-Based Applications
       "There is no memory with less satisfaction in it than the memory
            of some temptation we resisted." -- James Branch Cabell


+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 21 Jul 1994 20:57:20 GMT
Organization: Apple Computer

Laurence R. Brothers, [e-mail] writes:
> Keep in mind I'm used to an environment where you just don't have to
> worry about managing and dispatching your own events, and even
> updating windows will often be magically taken care of for you.  Most
> unix GUI toolkit objects either have useable default behavior, or you
> simply register callbacks for them. You never have to mess with the
> event loop in a typical X application unless you're doing something
> really weird and/or low-level. In fact if you use TCL/TK (that's a
> different TCL than the Mac acronym, by the way), almost every little
> thing is taken care of with amazingly acceptable default behaviour in
> the toolkit library.

You really need to start using one of the frameworks -- MacApp, TCL or
PowerPlant. They implement most of the nice things you describe above.

Keep in mind the historical legacy of the Mac: that it was built in the
early-'80s on a slow CPU with 128k of RAM (and originally it was only
supposed to have 64k.) There wasn't enough RAM or oomph to use object
oriented languages, and C++ didn't exist anyway. Nor was there enough memory,
or development time, to provide sophisticated libraries to do the work for
you. The goal of the Toolbox was to provide the facilities you'd need to put
together a Mac-style application, not to make it as easy as possible.

Unfortunately, it's never been possible to move away from that, since it
would have meant breaking every existing application. What _has_ been done is
to layer more sophisticated environments on top of the Toolbox, such as the
class libraries I mentioned above. I think you'll find those much more to
your taste.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Todd Vernon)
Date: Thu, 21 Jul 1994 21:14:01 GMT
Organization: NASA

--
> I don't intend to start a flame war about relative merits of things
> with this article, but I must say that as a programmer familiar with a
> variety of unix gui toolkits, ranging (historically) from Sunview all
> the way through TCL/TK, that my introduction to the Mac environment
> was rather a shock.

Hold on there sport.  I come from the same direction as
you but I have a little different perspective.

First of all.  You are comparing the Mac Toolbox to a
high level lib like Motif or TCL/TK ?  Try XLib.

Xlib is only moderatly better in a side by side comparison
then the MacToolbox.  Think of the Mac Toolbox as Xlib with
controls.  And yes they really are controls, you didn't have
to "draw" the button did you ?

If you choose to use the toolbox alone that is your biz, but I
would suggest something a little better, at least initially.
I use TranSkel and think it is really quite nice, and yes it
has the callbacks that are familiar to you.

Pay a little respect to the Mac roots, it was the first wide
spread use of GUI stuff.  It carries a little baggage.

As for MPW, well you made that choice, nothing can help you
there.  (try Code Warrior).



- ----------------------------------------------------------
  Todd Vernon                                    |\/\/\/|
  PRC Inc.                                       |      |
  NASA Dryden Flight Research Facility           |      |
  Edwards, CA 93523                              | (o)(o)
                                                 @      _)
                                                  | ,___|
  Phone: [phone]                             |   /
  FAX  : [phone]                            /____\
  Email: [e-mail]                /      \
- ----------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Thu, 21 Jul 1994 17:29:43 -0500
Organization: One Step Beyond

[e-mail] (Laurence R. Brothers) wrote:

) I don't intend to start a flame war about relative merits of things
) with this article, but I must say that as a programmer familiar with a
) variety of unix gui toolkits, ranging (historically) from Sunview all
) the way through TCL/TK, that my introduction to the Mac environment
) was rather a shock.
) [...]
) It must take at least 500 lines of C to produce a Mac application that
) is minimally conformant to the general rules of application behavior,
) [...]
) I also must admit that I have only been using MPW C, not MacApp or any
) of the C++ stuff as yet. I imagine that every Mac programmer must use
) some standard application framework to build their programs after a
) while, be it MacApp, AppWannaBe, or whatever, but still, the whole
) thing seems a lot more awkward than it really needs to be.

Gack.  You're using the most primative (interface wise) programming
environment and language on the Mac and programming to the metal (well
the raw OS anyway) and compare that against sophisticated X toolkits
for UNIX????

As you implied, if you should compare your X experience vs MacApp or TCL
or PowerPlant or Galaxy or XVT or...

If you weren't the kind of guy who did raw X programming, why do you
want to do raw Mac programming?  There are plenty of higher level tools
to choose from.  Go choose one.  Or build one, as it seems you are in
the process of doing :-).

In addition, remember that the Mac is a _personal_ computer, not a work-
station.  As such, it generally runs with much slimmer resources than
workstations.  32MB's of RAM is not common.  Only around 65% of Mac users
even have color.  Hell, a good 20% or 30% still use System 6 on 2MB or
less.

P.S. I would put the minimal LOC in C at a few thousand for a useless,
     but fully conformant Mac application.


That said, just for kicks, I'll try to explain some of the reasons the
Mac is the way it is.

) * What, I have to write my own event loop? Haven't they heard of
) callbacks?  Interposition? Well, I guess it's not a pre-emptive OS,

The original Mac was designed in '82/83 and was a single tasking machine.
When it came out, it had the most sophisticated and rich API of any
machine of its class available at the time.

In addition, in a cooperative environment, IMO, you need fine control
over event handling to be nice-nice with other apps.


) * I have to manage operating system events myself? What's the point of
) having an operating system if it can't manage its own events?

It does.  It simply notifies you when things happen.  Would you rather
it didn't?


) * OK, first I see the event is in the menu bar, then I adjust the
) menus to show what is active, then I call the menu tracking procedure,
) [...]
) something after checking the global state of the program.  How baroque.

If you only want simple menu selections, yes.  Some folks have to do more
complex things like tear-off menus that turn into floating palettes.

Same with scroll bars and other interface elements.


) * Oh well, at least the update event is the same. What, you say I
) shouldn't use backing store? Why not? Why provide the feature and then
) say not to use it?

The PicHandle thing for windows IS NOT a backing store.  You shouldn't
use a backing store because the average Mac today has only 4MB to 8MB
of real RAM.  That's not enough for backing stores.  The original had
only 128K of RAM.


) but still.... I would have thought the basic programming paradigm
) might have advanced slightly in the last 10 years, at least to the
) [...]

Nope.  There's this little thing called backward compatability that's
extremely important in the personal computer world.  UNIX people are
generally technical enough to roll with the punches, but secretaries,
artists and office workers would balk.

Apple is, of course, working on a pre-emptive kernal and memory protection
and all that other stuff.  But we gotta wait.  When they do come, the
days of free-form hacking and wild system patches will be gone.  Maybe
that's good, maybe that's bad...to each his own.

Well, that's enough for now.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 21 Jul 1994 17:32:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (Laurence R. Brothers) writes:

>I don't intend to start a flame war about relative merits of things
>with this article, but I must say that as a programmer familiar with a
>variety of unix gui toolkits, ranging (historically) from Sunview all
>the way through TCL/TK, that my introduction to the Mac environment
>was rather a shock.
>
> [ some interesting stuff omitted]
>
>I also must admit that I have only been using MPW C, not MacApp or any
>of the C++ stuff as yet. I imagine that every Mac programmer must use
>some standard application framework to build their programs after a
>while, be it MacApp, AppWannaBe, or whatever, but still, the whole
>thing seems a lot more awkward than it really needs to be.
>
>Of course all the above is IMHO only.... Of course there are many
>things available on the Mac platform that are either real expensive or
>very hard to implement in the typical unix environment. Still, I would
>really like someone to tell me: "You obviously haven't used the foo
>class libraries with the bar uims package and the baz event manager
>yet, so what do you expect".

Yes, you've got it right, even down to your suspicion that application
framework libraries like MacApp are what you are missing.  At one time
Apple hinted that a framework like MacApp might make it into ROM, but that
idea seems to have been abandoned, which in my opinion is just as well.  I
worked on Bedrock for two years, which was to be a next generation
framework (and may still become one in its reincarnation as the OpenDoc
Parts Framework).  My experiences tell me that we still have more to learn
about the right way to create application frameworks; putting one into ROM
at this point seems like a bad idea.

All of the established frameworks address many of the points you raise,
but none are without flaws.  So, you should survey the established
frameworks, pick one, and then be prepared to enter a love/hate
relationship with it.

Jim Lloyd
[e-mail]


+++++++++++++++++++++++++++

>From Bill North <[e-mail]>
Date: 21 Jul 1994 22:36:35 GMT
Organization: NASA Goddard Space Flight Center -- InterNetNews site

In article <[e-mail]>
Laurence R. Brothers, [e-mail] writes:
>
>A list of amazements as I started trying to develop some simple test
>applications to learn the Mac development environment:
>

Clearly, what you really want is to work on the Apple IIgs. :)
Much more advanced than the Mac. ;-)

Most of those things exist in the Apple IIgs toolbox. I never
understood why Apple never added the equivalent of IIgs calls
to the Mac, when the same company developed both toolboxes.

Why can't Apple add TaskMaster to the Mac? (TaskMaster handles
all "typical" system events: Window moving, scrolling, resizing,
etc; Menu selecting, highlighting, blinking, etc; Desk accessory
handling; Control activation, highlighting, etc.)

How about "HandleDiskInsert" on the IIgs, which will handle all
disk insert activities, including formatting.

Could go on, but...

Apple should apply the lessons learned from the IIgs and apply
them to the Mac.

/*  Bill North -- [e-mail]  */

+++++++++++++++++++++++++++

>From [e-mail] (Stuart R. Harper)
Date: Thu, 21 Jul 1994 18:52:34 -0400
Organization: Drexel U.

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:

> Laurence R. Brothers, [e-mail] writes:
> > Keep in mind I'm used to an environment where you just don't have to
> > worry about managing and dispatching your own events, and even
> > updating windows will often be magically taken care of for you.  Most
> > unix GUI toolkit objects either have useable default behavior, or you
> > simply register callbacks for them. You never have to mess with the
> > event loop in a typical X application unless you're doing something
> > really weird and/or low-level. In fact if you use TCL/TK (that's a
> > different TCL than the Mac acronym, by the way), almost every little
> > thing is taken care of with amazingly acceptable default behaviour in
> > the toolkit library.
>
> You really need to start using one of the frameworks -- MacApp, TCL or
> PowerPlant. They implement most of the nice things you describe above.
>
> Keep in mind the historical legacy of the Mac: that it was built in the
> early-'80s on a slow CPU with 128k of RAM (and originally it was only
> supposed to have 64k.) There wasn't enough RAM or oomph to use object
> oriented languages, and C++ didn't exist anyway. Nor was there enough memory,
> or development time, to provide sophisticated libraries to do the work for
> you. The goal of the Toolbox was to provide the facilities you'd need to put
> together a Mac-style application, not to make it as easy as possible.

That was an EXTREME cop-out. Reading Mr. Brothers list of complaints
reminded me of my own annoyance with programming the mac after moving over
from the Amiga, a 256K RAM/ROM, 68K based system. At the time of my change
('90), I couldn't believe that Apple provided an impressive guideline on
'how' the Mac should look and function without providing default actions
from system required user-interface features. Window management and
user-input code that took 3 or 4 lines to control suddenly took pages.

Requiring the development environment to push basic features invites all
kinds of compatibilty problems between systems, increases development time
with wasted compilation of 'standard' actions and increases the overall
code 'bloat'. Add that to the normal OOPS bloat and you've created
multi-megabyte monsters that require '040s and 601 just to grow the
window. :)

--
Stuart R. Harper - E4 Lab Technician - LeBow 132 - CCD - Drexel U.
[e-mail]        [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Arne Claassen)
Date: 21 Jul 1994 20:16:47 -0600
Organization: /usr/lib/news/organi[sz]ation

In article <[e-mail]>,
Jens Alfke  <[e-mail]> wrote:
>You really need to start using one of the frameworks -- MacApp, TCL or
>PowerPlant. They implement most of the nice things you describe above.
>

Being a Newbie to CodeWarrior and Macintosh C programming i felt a lot like
Lawrence. I looked at Powerplant and then decided to dig into the user manual
which explained to me that if i didn't have a good working knowledge of
the Toolbox and other such things, i should not bother with Powerplant yet.
So i'm going through Macintosh C primer and anything i can find and find myself
programming Event loops and stuff like that and never even getting to an
actual program aside from handling the basic interface.

I'm looking for something that let's me design the interface in a manner
similar to Visual C or similar and be able to concentrate on writing the code
that operates within the interface framework. Is this what Powerplant (or
MacApp, or whatever) does and how do i get started with it?

Thanks,

Arne F. Claassen
[e-mail]
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 22 Jul 1994 03:32:51 -0000
Organization: Delphi Internet Services Corporation

[e-mail] (Laurence R. Brothers) writes:


>I don't intend to start a flame war about relative merits of things
>with this article, but I must say that as a programmer familiar with a
>variety of unix gui toolkits, ranging (historically) from Sunview all
>the way through TCL/TK, that my introduction to the Mac environment
>was rather a shock.

>Keep in mind I'm used to an environment where you just don't have to
>worry about managing and dispatching your own events, and even
>updating windows will often be magically taken care of for you.  Most
>unix GUI toolkit objects either have useable default behavior, or you
>simply register callbacks for them. You never have to mess with the
>event loop in a typical X application unless you're doing something
>really weird and/or low-level. In fact if you use TCL/TK (that's a
>different TCL than the Mac acronym, by the way), almost every little
>thing is taken care of with amazingly acceptable default behaviour in
>the toolkit library.

John Ousterhout's new group at Sun is apparently working on a Mac
port of Tk.  There's already an "unofficial" port of Tcl.

>A list of amazements as I started trying to develop some simple test
>applications to learn the Mac development environment:

>* What, I have to write my own event loop? Haven't they heard of
>callbacks?  Interposition? Well, I guess it's not a pre-emptive OS,
>but still, does that make any difference?

You're trying not to start a flame war?  "I ask merely for
information."

>* I have to manage operating system events myself? What's the point of
>having an operating system if it can't manage its own events?

Hey, go check out Windows before you complain about Macintosh's
handling of events.

>* I have to write an event procedure in case someone inserts an
>unformatted disk? Give me a break. How about I request a notification
>only if I'm interested in a bad disk event, and otherwise you take
>care of it, Mr. Disk Manager? No deal? Too bad.

>* OK, first I see the event is in the menu bar, then I adjust the
>menus to show what is active, then I call the menu tracking procedure,
>then I divide a long int into two "words" (gee, 16 bit words, I wonder
>where that came from -- me, I call it a half-word.... :-), then I find
>out which menu and item it was, then I get to actually have my own
>code do something after checking the global state of the program.  How
>baroque.

>* Wait a minute, this isn't a scrollbar, it's just a bit of graphics.
>It doesn't actually *do* anything. It takes a page of code just to get
>to the point that you find out which scrollbar thingie got clicked on,
>then you have to do it all yourself. Apple wouldn't have to have all
>this style guide stuff if they actually implemented any functionality
>anywhere.

>* Hmm... I guess the zoom box and the grow icon don't do anything
>either. Well, gee, at least I have system zoom and grow procedures,
>but my event procedure needs at least a page of checks surrounding
>each one before I can call it. Same thing for window movement.

>* Hey wait a second, you mean I actually have to activate and
>deactivate the windows myself? I have to deselect the controls, and
>all that? Oh come on....

>* I guess geometry management is too much to ask for? Oh well. Should
>have known better than to ask. Of course there are no subwindows on
>the Mac anyhow, so I guess there's not much point.

You think subwindows are a good thing? I can see why they would be
used in X and all those other GUIs, but the Mac has a Human Interface.
They really wouldn't fit.

>* Oh well, at least the update event is the same. What, you say I
>shouldn't use backing store? Why not? Why provide the feature and then
>say not to use it?

>                ...


>Well, you can see what I mean, if you have any familiarity with your
>typical Unix/X toolkit (which I had previously thought of as the
>pessimal programming environment!)

>I have to qualify all this by saying I've only been messing around
>with Mac programming for a few weeks, so I am not used to it all yet,
>but still.... I would have thought the basic programming paradigm
>might have advanced slightly in the last 10 years, at least to the
>extent of a standard re-entrant toolkit event-loop with callbacks and
>event interposition instead of all this manual dispatching. Even in an
>antique like Sunview you could code a typical application in probably
>1/5 to 1/2 the space of an equivalent Mac application.

Unlike Sunview, X, Motif, etc, Macintosh has a considerably large
installed base.  The people forming the installed base would be rather
upset if all the applications they use suddenly broke overnight.

[snip]

>Of course all the above is IMHO only.... Of course there are many
>things available on the Mac platform that are either real expensive or
>very hard to implement in the typical unix environment. Still, I would
>really like someone to tell me: "You obviously haven't used the foo
>class libraries with the bar uims package and the baz event manager
>yet, so what do you expect".

You haven't tried the PowerPlant class library, which is included with
CodeWarrior, so what do you expect?

>--
>             Laurence R. Brothers ([e-mail])
>  Bellcore -- Computing Technology Integration -- Knowledge-Based Applications
>       "There is no memory with less satisfaction in it than the memory
>            of some temptation we resisted." -- James Branch Cabell

......................................................................
Chris Thomas, Programmer, Echo Software, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Elizabeth Scharf)
Date: 22 Jul 1994 04:36:32 GMT
Organization: University of Washington, Seattle

This reminds me of Jerry Pournelle's infamous quote in 1984 to the effect
that the problem with the Macintosh was that "they wrote half of the
operating system and left the other half as an exercise to the reader."

Fortunately, things have progressed a little since then...

rmgw

This is not my account:  Please address replies to [e-mail]

Disclaimer:  All views expressed are entirely my own and do not reflect
the opinions of Elizabeth Scharf or the University of Washington.

- ---------------------------------------------------------------------------
Richard Wesley             | "If I can't dance, you can keep your
[e-mail]           |  revolution."
[e-mail]  |        - Emma Goldman
- ---------------------------------------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (Ted C Brown)
Date: 22 Jul 1994 05:33:23 GMT
Organization: The Ohio State University

In article <30mpgl$[e-mail]>,

>Yes, you've got it right, even down to your suspicion that application
>framework libraries like MacApp are what you are missing.  At one time
>Apple hinted that a framework like MacApp might make it into ROM, but that
>idea seems to have been abandoned, which in my opinion is just as well.  I
>worked on Bedrock for two years, which was to be a next generation
>framework (and may still become one in its reincarnation as the OpenDoc
>Parts Framework).  My experiences tell me that we still have more to learn
>about the right way to create application frameworks; putting one into ROM
>at this point seems like a bad idea.

I don't really want the app frameworks in ROM, I want the base classes to
exist in one place in memory, probably loaded by an extention, and for
programs to dynamically link to them.  The main problem with this is
that we'd have to settle on one app framework.  Well maybe not --
having the PowerPlant/MacApp/TCL load all at once would eat up alot
of memory, but dramatically reduce the code/memory needs of every program
that used them.

Maybe Dylan will do this (you'd think it'd be able to handle the Dynamic
Linking part).


+++++++++++++++++++++++++++

>From [e-mail] (Matt Burch)
Date: 21 Jul 1994 20:24:36 -0500
Organization: Kansas State University

For most of the stuff you mentioned, I use the freeware
TransSkel 3.0. It does all the event handling, menus, windows, etc.
and calls my callback routines when something relavent happens.
Easy as 3.1415927.

--
- -------------------------------------------------------
Matt Burch | [e-mail] | Cogito, ergo cogito sum
- -------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Russell LaVelle)
Date: 22 Jul 1994 14:27:16 GMT
Organization: InfiNet

Ted C Brown ([e-mail]) wrote:
: In article <30mpgl$[e-mail]>,

: >Yes, you've got it right, even down to your suspicion that application
: >framework libraries like MacApp are what you are missing.  At one time
: >Apple hinted that a framework like MacApp might make it into ROM, but that
: >idea seems to have been abandoned, which in my opinion is just as well.  I
: >worked on Bedrock for two years, which was to be a next generation
: >framework (and may still become one in its reincarnation as the OpenDoc
: >Parts Framework).  My experiences tell me that we still have more to learn
: >about the right way to create application frameworks; putting one into ROM
: >at this point seems like a bad idea.

: I don't really want the app frameworks in ROM, I want the base classes to
: exist in one place in memory, probably loaded by an extention, and for
: programs to dynamically link to them.  The main problem with this is
: that we'd have to settle on one app framework.  Well maybe not --
: having the PowerPlant/MacApp/TCL load all at once would eat up alot
: of memory, but dramatically reduce the code/memory needs of every program
: that used them.

You want a Shared Library, which is possible in the PPC.

: Maybe Dylan will do this (you'd think it'd be able to handle the Dynamic
: Linking part).

Thats axactly waht Dylan does. There is a Dylan Core that goes in the
extensions folder. Also, the developer can choose to link the core in to the
final app if they want stand alone.

--
MacXperts, Inc.                     804.353.7122
Certified Apple Developers          fax [phone]
3228-L West Cary St.                applelink: xperts
Richmond, VA  23221                 net: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 22 Jul 1994 17:44:32 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Laurence R. Brothers) writes:

>Keep in mind I'm used to an environment where you just don't have to
>worry about managing and dispatching your own events, and even
>updating windows will often be magically taken care of for you.  Most

Well, using a GUI toolkit for the Mac, like MacApp, TCL or the
non-C++ TransSkel, will take care of that for you. No muss no fuss.

>* What, I have to write my own event loop? Haven't they heard of
>callbacks?  Interposition? Well, I guess it's not a pre-emptive OS,
>but still, does that make any difference?

Do it once, then it's done. Or use one of the libraries available
and pointed out in the FAQ. If you really want to, this means you
can get more control if you really want to.

>* I have to manage operating system events myself? What's the point of
>having an operating system if it can't manage its own events?

What do you mean operating-system events? The only one I can think
of is the diskEvent, which, again, is handled by all available libraries,
or you write it once from sample code and forget it - the pro is that
you can intercept the event and do something interesting to the floppy
if you want to.

>I also must admit that I have only been using MPW C, not MacApp or any
>of the C++ stuff as yet. I imagine that every Mac programmer must use

See, there you go. It's like trying to write something in XLib.
You CAN, but it's not a good idea. For plain C, try TransSkel.

>while, be it MacApp, AppWannaBe, or whatever, but still, the whole
>thing seems a lot more awkward than it really needs to be.

Have you ever used XLib?

--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --

"Something horrible is wrong."
    - Steve Falkenberg

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Fri, 22 Jul 1994 17:46:26 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (AFC JLloyd) writes:
>Yes, you've got it right, even down to your suspicion that application
>framework libraries like MacApp are what you are missing.  At one time
>Apple hinted that a framework like MacApp might make it into ROM, but that
>idea seems to have been abandoned, which in my opinion is just as well.  I
>worked on Bedrock for two years, which was to be a next generation
>framework (and may still become one in its reincarnation as the OpenDoc
>Parts Framework).  My experiences tell me that we still have more to learn
>about the right way to create application frameworks; putting one into ROM
>at this point seems like a bad idea.

>All of the established frameworks address many of the points you raise,
>but none are without flaws.  So, you should survey the established
>frameworks, pick one, and then be prepared to enter a love/hate
>relationship with it.

       The basic problem is that all the Mac frameworks are lousy.
Apple's MacApp is big, old, clunky, and weakly supported.  Last year at this
time, Apple was telling developers to go to Symantec's Bedrock, which
got as far as a CD-ROM with the Bedrock headers and some sample apps
before being dropped.  Symantec has the "old TCL", written for their
dialect of C with some C++ extensions; it's widely used, more or less
stable, and on the way out.  Symantec also has the "new TCL", which is
true C++, very new, and very buggy.  Symantec is generally considered
to be concentrating on the Windows market now.  Then there's the new
vendor, MetroWerks, which is selling an almost-finished C++ compiler
(no templates) and a somewhat thin class library that goes with it.
Generally, users of MetroWerks are happier with their vendor than
Symantec users.

        There's also the "Nerdworks" library, which is a free class
library available on Apple's "ftp.apple.com", and there's a book that
goes with it.  This is a weak, but workable class library.

        At the high end, there are some tools from Neuron Data that
allow cross-platform development, but pricing is in the $10K and up
range.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Stan Shebs)
Date: Fri, 22 Jul 1994 18:51:39 GMT
Organization: /cygint/s1/users/shebs/.organization


In article <[e-mail]> [e-mail] (Laurence R. Brothers) writes:

   * What, I have to write my own event loop? Haven't they heard of
   callbacks?  Interposition? Well, I guess it's not a pre-emptive OS,
   but still, does that make any difference?

When I first wrote Xconq for X10, when the Xt toolkit was too broken to use,
guess what, I had to write my own event loop!

Actually, the value of the explicit event loop is that you can bypass
when necessary.  A heavily-tuned Mac program can have a number of event
loops, such as the one that handles the spiffy scrollbar response when
you're dragging the thumb.  This kind of thing really helps performance.

In general, Mac applications (binaries, not sources) are smaller and
use the CPU more efficiently than Unix/X applications.  It's very educational
to put a 68000-based Mac Plus side-by-side with a Sparc-based Sun machine,
and watch the Plus run interactive programs smoother and faster than the Sun!

   * Wait a minute, this isn't a scrollbar, it's just a bit of graphics.
   It doesn't actually *do* anything. It takes a page of code just to get
   to the point that you find out which scrollbar thingie got clicked on,
   then you have to do it all yourself. Apple wouldn't have to have all
   this style guide stuff if they actually implemented any functionality
   anywhere.

What makes you think that everybody wants to do scrollbars the same
way?  There are many application-specific optimizations and variations
available.  If you ever get to a point where you need to do one of these,
you'll be very glad it's not in ROM!

Incidentally, the guidelines are intended only as a starting point.  Many of
the interface developments of the past ten years started out by violating
some guideline, but then went on become part of the guidelines themselves.
Just compare a 1984 IM with the latest HIG...

   * I guess geometry management is too much to ask for? Oh well. Should
   have known better than to ask. Of course there are no subwindows on
   the Mac anyhow, so I guess there's not much point.

After having wasted months and years of my life messing with X's yucko
notions of "geometry management", I was very happy not to have that on
Macs.

   I have to qualify all this by saying I've only been messing around
   with Mac programming for a few weeks, so I am not used to it all yet,
   but still.... I would have thought the basic programming paradigm
   might have advanced slightly in the last 10 years, at least to the
   extent of a standard re-entrant toolkit event-loop with callbacks and
   event interposition instead of all this manual dispatching. Even in an
   antique like Sunview you could code a typical application in probably
   1/5 to 1/2 the space of an equivalent Mac application.

Of course, the main application that everybody runs in a "modern" Unix
environment is a terminal emulator set to mimic terminals from 10-20 years
ago, still you type "ls" and "rm" just like Ken and Dennis did, and
heaven help you if you try to write a program that doesn't have a console
available for stdout to write to, even if it *is* an "toolkit event-loop
with callbacks".

I think you'll find that it takes more than a few weeks to realize that
the Unix style of programming is not the only way, and that the Mac style,
in addition to its weaknesses, has many strengths that the Unix world has
yet to approach.

   It must take at least 500 lines of C to produce a Mac application that
   is minimally conformant to the general rules of application behavior,
   probably more. IMHO, even a 3 line hello world program should
   automagically do all "the right things" because the windowing
   environment/finder/OS/whatever should take care of it all.

That's not exactly fair, because the "3-line hello world" of Unix doesn't do
*any* interaction at all.  If I just wanted to scribble on the screen and
exit, I could write a pretty short Mac program for that, and do it with just
the basic Mac traps.

Also, once the basic framework is in place, you don't have to mess with it
anymore.  I now have versions of Xconq for both Macs and X11, and it's
*much* easier to add a new menu item or button or image to the Mac version,
so much so that my Mac version usually gets all the features first.

   Of course there are many
   things available on the Mac platform that are either real expensive or
   very hard to implement in the typical unix environment.

Amen to that!  Try having a reasonable response time when dragging
something with the mouse.  Can you say "stu-stutt-stu-st-stutter"?

   Still, I would
   really like someone to tell me: "You obviously haven't used the foo
   class libraries with the bar uims package and the baz event manager
   yet, so what do you expect".

Others have gone into the details, so I'll just leave it at the "what do you
expect". :-)

                            Stan Shebs
                            Cygnus Support
                            [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 22 Jul 1994 17:24:12 GMT
Organization: Apple Computer

Stuart R. Harper, [e-mail] writes:
> That was an EXTREME cop-out. Reading Mr. Brothers list of complaints
> reminded me of my own annoyance with programming the mac after moving over
> from the Amiga, a 256K RAM/ROM, 68K based system.

Well, I'm not saying that the design of the Mac OS was perfect; I think they
really screwed up in some areas and we're still paying the price for that.
Your point about the Amiga is valid; nevertheless, note that the Amiga came
out a few years after the Mac and was able to learn from some of its mistakes
(the same can be said for Windows). Also, both may seem tiny by today's
standards but there is a _big_ difference between a system with 256k each of
RAM and ROM, and one with 128k RAM and 64k ROM. The Amiga had twice the RAM
(which means much more RAM available to apps) and four times the ROM, so that
gave them more headroom to put in things like e.g. threading and an improved
Toolbox interface.

> Requiring the development environment to push basic features invites all
> kinds of compatibilty problems between systems, increases development time
> with wasted compilation of 'standard' actions and increases the overall
> code 'bloat'.

Good dynamic linking technology, as is finally starting to appear on the Mac
with ASLM and SOM, will take care of a lot of that. (Note that the NeXT
application framework is a shared library living on top of a very Mac-like
lower level toolbox.) I really don't care whether the code that handles my
basic app functionality is in ROM or in a shared library; it looks the same
to me, and the library is easier to update and maintain. OpenDoc and its
framework will take advantage of this in a big way.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Fri, 22 Jul 1994 18:21:07 GMT
Organization: ISIS International

Look at one of the class libraries or application frameworks such as TCL,
MacApp, or PowerPlant. All of them take care of the event dispatching & all
of the other things that you're so grossed out about - you only have to add
your own callbacks by overriding various behaviours, such as clicking in the
content are of a pane. They even handle scrolling by providing a scroller
object which does most of the work.
--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: file://ftp.netcom.com/pub/isis/home.html

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Fri, 22 Jul 1994 18:32:14 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)


Just to add my fuel to the flame war:

There is geometry management, if you want it, so it doesn't cost you
anything if you don't use it. You get it by writing rez #define expressions.
This lets you line dialog items up, or arrange them any way you like,
but at compile time, rather than run time.

Ever try to write copy and paste in motif? There are multiple, incompatible
definitions of the clipboard, so doing what on a mac is
ZeroScrap()
PutScrap()

takes pages of code to do correctly (read the emacs source for an example.)
- - - -
Callbacks are just syntactic sugar around X's event loop. If you know,
because you are writing your program, what procedure you are going to call
in response to an event, then it is much simpler to simply call the procedure:
for(;;){
    GetNextEvent(everyEvent, &event);
    switch(event->what){
    case keyDown: GoKey(&event);    break;
    ...
    }
}

as opposed to the mysterious:
    XtAddCallback(rootWidget, XmNkeyDownEventCallback, GoKey, NULL);

In fact, Apple has lost the vision, and started importing to many unix heads:
the interface to the Applescript inter-application communication system looks
like it was designed by Unix wannabees.

When you are trying to debug a program, it is much easier to put a single
breakpoint in an explicit event loop, and trace it than it is to have the
heart of the program embedded in some system undebuggable library, and have
to set breakpoints in ALL your callbacks because you don't know which one
will trigger.

X gives you no help with printing: once you write your application to
do its drawing to the screen, you need to write it a second time to
directly generate postscript, so you can write a text file of postsript
to send to the printer. On the mac, you open a printer GrafPort, and
do the same drawing to it that you do to the screen. The translation
to the printer driver happens automatically.

Then of course, there is the speed of progress in the two environments.
At least there is a standard inter-application communication system for
the Mac.  Unix still hasn't fixed the security bug in "login" I reported
back in 1977 : 17 years ago.

I've done numerous commercial products on Macintosh and on Unix/Motif.
Macs are much easier to program at the toolbox level than Unix/Motif.

+++++++++++++++++++++++++++

>From Rob Browning <[e-mail]>
Date: 22 Jul 1994 19:30:30 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <30p0i0$[e-mail]> Jon W!tte, [e-mail] writes:
>>Keep in mind I'm used to an environment where you just don't have to
>>worry about managing and dispatching your own events, and even
>>updating windows will often be magically taken care of for you.  Most

Une thing that I would mention is that MCL (Yes that's Macintosh Common
Lisp) has a very impressive class library that handles your interface
with the Mac Toolbox.  It has callbacks, it handles the event loop behind
your back, and you don't ever have to call WaitNextevent (but you can if
you like).

It supports windows which contain views which contain subviews...  And
you just subclass one of these and override it's view-draw-contents
method, and you are on your way.  All this and much much more :>

And not to start a religious war, but if you put in all the type
declarations in your code (the ones that you have to put in a C/C++
program) you can get quite good performance.  No, it won't beat C or C++ on
a reguar basis, But as a development/prototyping environment, it is quite
impressive.  It's too bad it looks like it is going the way of the DoDo.
MCL shows what Apple can do if they put their mind to it.  And as good as
Dylan sounds, it's not quite as powerful as Common Lisp.

--Rob.

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 22 Jul 1994 20:23:12 GMT
Organization: (none)

[e-mail] (Matt Burch) writes:

>For most of the stuff you mentioned, I use the freeware
>TransSkel 3.0. It does all the event handling, menus, windows, etc.
>and calls my callback routines when something relavent happens.
>Easy as 3.1415927.

One of the *best* things with TransSkel is that while it does simplify the
programming a lot (making trivial programs trivial to write) I still have
full access to the Toolbox as much as I *want*.

For example, when I wanted to handle suspend/resume events, using TransSkel
2.0 (which was made before suspend/resume was invented), I could add that
without editing TransSkel at all!

I still use TransSkel 2.0 (updated for some "new" stuff like WNE and
hierarcical menus), and it works just great. I guess 3.0 is better,
but it doesn't come with Pascal-useable TransEdit and TransDisplay.

Programming the Mac from the ground up from the Toolbox, without a package
like that, is really confusing. Getting into stuff like Apple Events,
Appletalk and QuickTime is even worse. I find myself writing simplified
interfaces to all of them as I start using them. You can go to that level
later, but do yourself a favor and start on a level that is simpler.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Arne Claassen)
Date: 22 Jul 1994 15:04:21 -0600
Organization: University of Denver, Dept. of Math & Comp. Sci.

In article <30n74k$[e-mail]>,
Matt Burch <[e-mail]> wrote:
>For most of the stuff you mentioned, I use the freeware
>TransSkel 3.0. It does all the event handling, menus, windows, etc.
>and calls my callback routines when something relavent happens.
>Easy as 3.1415927.

Where can i find TransSkel? I've tried archie and sumex-aim. but to no
avail. is it under a different name than transskel?

Arne F. claassen
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Shimpei Yamashita)
Date: 23 Jul 1994 10:22:40 GMT
Organization: Stanford University, CA 94305, USA

In article <30pc8l$[e-mail]>,
Arne Claassen <[e-mail]> wrote:

:Where can i find TransSkel? I've tried archie and sumex-aim. but to no
:avail. is it under a different name than transskel?
:
:Arne F. claassen
:[e-mail]
:
:
ftp.primate.wisc.edu in /pub/mac/TransSkel

Would someone like to upload it to sumex? I just got it, and I don't want
to upload anything I haven't evaluated for a few days.
--
Shimpei Yamashita, Stanford University           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 24 Jul 1994 10:52:09 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Stuart R. Harper) writes:

>Agreed! Quick adoption of ASLM will make up for alot of real or perceived
>problem in Mac code development i.e. You don't like rolling all your own
>UI code, find GUI library that you like that does the job for you.

ASLM is doomed to die; except OpenTransport will use it so it
has to survive :-(

ASLM does dynamic linking of C++ classes compiled with MPW C++
(CFront) For other things, with other compilers/environments,
it doesn't work.

SOM is the future, and it will be on top of the CFM which is _here_
in production, release, use, ... since March 14.

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --

"Windows doesnUt use AppleEvents."
    - Anon

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Sun, 24 Jul 1994 10:45:55 GMT
Organization: The Information Workshop


There have been many enlightened observations, and a few chuckles, too,
regarding a lot of related things.

I was rolling on the floor when I read the one about where...

     "The Mac was built only half-way, and the
      rest was left as an exercise for the reader."


But with respect to identifying the real source of Mr. Brother's
programming problems, you've all missed it.

  --------------------------------------------------------------
   The problem is with HOW one is introduced to any new subject.
  --------------------------------------------------------------

If an excellent guide were sitting next to him for a week or two, he
would still be having a pleasant experience, regardless of platform, and
probably out-producing most of the rest of his colleagues.

But, every last one of us is thrown into any new subject, sink or swim...


- --

When it gets frustrating, we question the design.  :)  And rightly so!

But when we're finally making progress, we forget, and go back to
accepting things the way they are.

And "acceptance" is what perpetuates "the trap", where we are all so busy
trying to catch up that we never have any extra time to help make things
better.


- --- The Power of Simplicity

Simple "guided introductions" into a new <whatever> can mean 5,000 people
working productively with <whatever>, instead of 50.

It means avoiding and preventing humongous amounts of floundering,
repeating classic mistakes, repeated questions, and having to reverse
incorrect models we've created in our heads.

And so easily done.  It doesn't take much.


- --- Case In Point As We Speak

Mark my words.  You read it here (too).

In three years we'll all be wondering why it has taken forever for
OpenDoc to catch on.  Everyone will have an opinion.

Yes, there were the "guided introductions" into the fabulous world of
OpenDoc made available through Apple's Developer University, but their
effectiveness was negated by Apple needing to make a return on its
investment in developing its tutorials, rather than its investment in the
supply of OpenDoc-savvy programmers, and as a consequence only 50
programmers purchased them.


Well...

  What did we expect when we take an existing set of programmers,
  and then ALL AT ONCE ask them to...

     * learn how to use a second development environment
       (MPW or ToolServer) along with their primary one,
       with many ALSO switching to a new primary environment.

     * learn C++.

     * learn the tricks of the trade for writing programs that
       run correctly on the PowerMacintosh.

     * get their object-oriented savvy developed so they too can
       speak comfortably of mixin classes, operator overloading,
       iostreams, templates, virtual destructors, unmangling,
       and the relative merits of various class libraries.

     * Get up ot speed on at least one of Apple's new technologies,
       which includes AppleScript/OSA, Drag Manager, AE/Object,
       AOCE, Threads, CommToolbox/TCP, Components/ASLM, new printing
       architecture, etc.

     * Produce sellable OpenDoc parts by mastering OpenDoc's
       new paradigms, new terms and concepts, normally large class
       library, IBM's SOM, and the new tools that work with them.


That's "the shock of the new".

How can we expect programmers to make progress when they are "thrown in"
to handle all of this, unguided, sink or swim, and offered no way to get
past dog-paddling?

Every question in csmp that has been asked before is DOG-PADDLING.

Every valuable question/answer that is not saved and made easily
re-accessible in a central place perpetuates DOG-PADDLING.


- ---------------------------------------------------------------------

... and all this just seems to go in one ear, and out the other, 'cuz
things go right back to the way they were, just like the discussion in
this thread will.

Watch...

:)


Mark Hanrek
The Information Workshop

+++++++++++++++++++++++++++

>From [e-mail] (Stuart R. Harper)
Date: Sat, 23 Jul 1994 11:44:58 -0400
Organization: Drexel U.

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:

> Stuart R. Harper, [e-mail] writes:
> > That was an EXTREME cop-out. Reading Mr. Brothers list of complaints
> > reminded me of my own annoyance with programming the mac after moving over
> > from the Amiga, a 256K RAM/ROM, 68K based system.
>
> Well, I'm not saying that the design of the Mac OS was perfect; I think they
> really screwed up in some areas and we're still paying the price for that.
> Your point about the Amiga is valid; nevertheless, note that the Amiga came
> out a few years after the Mac and was able to learn from some of its mistakes
> (the same can be said for Windows). Also, both may seem tiny by today's
> standards but there is a _big_ difference between a system with 256k each of
> RAM and ROM, and one with 128k RAM and 64k ROM. The Amiga had twice the RAM
> (which means much more RAM available to apps) and four times the ROM, so that
> gave them more headroom to put in things like e.g. threading and an improved
> Toolbox interface.

True enough, but when the Mac+ and MacII made their rollouts with their
128KROM and 256KROM, Apple still didn't see fit to add a "Default Action
Manager" or update the Toolbox/Event Manager to take care of basic
user-interface function. Yeah, I know, they had alot of other development
going on (Color QuickDraw, 020 migration, Networking etc), but adding a
basic event->action or even a shared library framework to the ROM would
have made accessing new features a breeze.


> > Requiring the development environment to push basic features invites all
> > kinds of compatibilty problems between systems, increases development time
> > with wasted compilation of 'standard' actions and increases the overall
> > code 'bloat'.
>
> Good dynamic linking technology, as is finally starting to appear on the Mac
> with ASLM and SOM, will take care of a lot of that. (Note that the NeXT
> application framework is a shared library living on top of a very Mac-like
> lower level toolbox.) I really don't care whether the code that handles my
> basic app functionality is in ROM or in a shared library; it looks the same
> to me, and the library is easier to update and maintain. OpenDoc and its
> framework will take advantage of this in a big way.

Agreed! Quick adoption of ASLM will make up for alot of real or perceived
problem in Mac code development i.e. You don't like rolling all your own
UI code, find GUI library that you like that does the job for you.

--
Stuart R. Harper - E4 Lab Technician - LeBow 132 - CCD - Drexel U.
[e-mail]        [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sun, 24 Jul 1994 17:10:21 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Rob Browning <[e-mail]> writes:
>In article <30p0i0$[e-mail]> Jon W!tte, [e-mail] writes:
>>>Keep in mind I'm used to an environment where you just don't have to
>>>worry about managing and dispatching your own events, and even
>>>updating windows will often be magically taken care of for you.  Most

>Une thing that I would mention is that MCL (Yes that's Macintosh Common
>Lisp) has a very impressive class library that handles your interface
>with the Mac Toolbox.  It has callbacks, it handles the event loop behind
>your back, and you don't ever have to call WaitNextevent (but you can if
>you like).

       Is this still an active product?  Is there a PPC version?

       We used to think Common LISP was big.  Then came C++.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 24 Jul 1994 17:45:49 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> Mark Hanrek <[e-mail]> writes:

>Simple "guided introductions" into a new <whatever> can mean 5,000 people
>working productively with <whatever>, instead of 50.

If the <whatever> is the Mac toolbox, there are courses from
the Developer University, both self-paced and on-site. They
are expensive, but from what I hear, very good.

>It means avoiding and preventing humongous amounts of floundering,

The FAQ for this group is intended to at least give a hint of what
you should do in that situation.

>That's "the shock of the new".

Well, with these new technologies, and OpenDoc specifically, it
seems as if Apple is trying to bet it all on one card: We Want The
Future To Be Like This. Unfortunately, they don't do it with all
their hearts, orr rather, with all their wallet, just with all of
their minds, which may explain why Apple seems so mindless of
other things :-)

I can envision a future where OpenDoc works the wonders it's supposed
to do, but as you say: it's all about adoption. And adoption right
now is not feasible; there's not even a sanctioned way of using a
scroll bar...

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --

  I offer a pot of gold for Gates' head on a pole.
  Naah - bashing Microsoft is "out." Love, Peace and Understanding!

+++++++++++++++++++++++++++

>From [e-mail] (Arne Claassen)
Date: 24 Jul 1994 14:43:57 -0600
Organization: University of Denver, Dept. of Math & Comp. Sci.

In article <[e-mail]>, John Nagle <[e-mail]> wrote:
>       Is this still an active product?  Is there a PPC version?
>
>       We used to think Common LISP was big.  Then came C++.

The last version is MCL 2.0 and available from APDA. Dunno the price, but i'd
say about $500.

MCL 2.0 is an updated version of Franz's Allegro Common LISP and does include
CLOS (Common Lisp Object System) as to the specifications discussed by Guy
Steele in Common Lisp: The Language, second edition. It does not, however
include CLIM (Common LISP Interface Manager) which will allow transporatable
application development for all Common LISP platforms. CLIM is available in
beta (maybe later by now) form from a number of independent developers.
Forget support from Apple, tho. You'd actually get more helpful info from Franz
although they don't support it either.

So, no PPC and not likely either.

On the other hand, for large applications, it's a great development platform,
does include excellent tools for dealing with interface elements and implements
the Event Loop in the environment.

Of course there's always the overhead. A simple application will take almost
a Meg in LISP overhead for the compiled application, but if you build a five
meg application, that's not too bad (HMM.. me thinks, MS Windows was developed
in LISP with their overhead... :)

Arne F. Claassen     [e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Arne Claassen)
Date: 25 Jul 1994 07:30:39 -0600
Organization: University of Denver, Dept. of Math & Comp. Sci.

In article <30voj2$[e-mail]>,
Jon Wdtte <[e-mail]> wrote:
>In <30u5jq$[e-mail]> [e-mail] (Damir Smitlener) writes:
>>Until there is something like Visual C++ (if there is and i havent
>>seen it, please tell me! and i dont mean multi-thousand dollar
>>packages.), ile leave 'Mac' programming to those who want it.
>
>Why not pay a few thousand dollars for a good package? You paid
>a lot for you Mac, you're going to earn your living with it, so
>you'd better have decent tools, right?

Um, i the point is that on inferior (ok, if someone wants to flame me for
calling Windows inferior, go right ahead) platforms there are excellent tools
for developing software and one can worry less about meeting the overhead
needed for a program that fits well into the platform. While on the mac, there
really isn't anything like cheap tools, such as Visual C++, so why should i
spent more money than a Windows developer? Because of the glory and
warm'n'fuzzy-feeling of programming for the Macintosh? Um, i love my Mac and
i'll never go back to PCs, but i don't see why there cannot be a development
environment worth the OS we work with.
>
>>All these defenses of mac-programming here confuse me; do you
>>folks WANT to work that hard on non-essentials? Doesnt anyone
>
>No; we DON'T work hard on essentials. Either we did it once
>before, and copy/paste into a new project, or we use one of the
>many good environments/frameworks available. But if you're the
>typical lazy integrator consultant type, I'm not surprised you
>don't want to do the research necessary before condemning a
>platform you haven't used for any extended period of time.

I'm doing research and i'm getting places, but it's still annoying. But
defending the intrinic necessity for the overhead in even handling and
interface management, strikes me in much of the same way as the arguments
from unix-people i know that try to convince me of the intrinsic superiority
command lines as opposed to GUIs (another posssible flame war, but i'd rather
not get into that one)

Arne F. Claassen
- --
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Damir Smitlener)
Date: 24 Jul 1994 12:41:30 -0400
Organization: Georgia Institute of Technology

>How can we expect programmers to make progress when they are "thrown in"
>to handle all of this, unguided, sink or swim, and offered no way to get
>past dog-paddling?

Simple answer: you cant. As a relative newcomer to the mac, but
not to programming in general, I write NO software that can be
considered 'Mac-like.' I write using standard c/c++, which means
i basically write unix-code. To take this code to windows has
proven quite painless with tools like Visual C++. Going to X ,
not too bad.

Making it Mac software? Uhh...ime simply not interested in working
that hard on stuff that should be handled be the OS. Yes, Ive
looked at TransSkel, PowerPlant, etc. Compared even to Visual BASIC
they _suck_.

Until there is something like Visual C++ (if there is and i havent
seen it, please tell me! and i dont mean multi-thousand dollar
packages.), ile leave 'Mac' programming to those who want it.

All these defenses of mac-programming here confuse me; do you
folks WANT to work that hard on non-essentials? Doesnt anyone
wonder why Doom will be running on SGI and anything that runs
linux before it runs on Macs? In fact, ile make a prediction:
Doom will run as a linux app on PowerMacs before it runs as
a System 7.x app.

Still, i am impressed by the skill of those who can do this well.
I wont be one of them, even though i love my powermac.

damir
[e-mail]







+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 25 Jul 1994 22:17:57 GMT
Organization: Apple Computer

Jon W!tte, [e-mail] writes:
> I can envision a future where OpenDoc works the wonders it's supposed
> to do, but as you say: it's all about adoption. And adoption right
> now is not feasible; there's not even a sanctioned way of using a
> scroll bar...

Hmm, you mentioned this once before in private e-mail. To do scrolling you
just use two frames; it's really almost exactly the way it works in MacApp
with a scroller view embedding the view to be scrolled. There is a new recipe
that describes how to do scrolling, which I can e-mail you.

Really, is this the main objection you have to OpenDoc? These things can seem
tricky, but recall all the problems you must have had figuring out how to do
scrolling and growing windows when you first learned to program the Mac ... I
know that moving the scrollbars around and invalidating the proper areas of
the window gave me fits. It's just a matter of learning new things.

And, back to the theme of this thread, the OpenDoc Parts Framework will take
care of the grungy details of scrolling for you.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: Tue, 26 Jul 1994 10:02:53 +0200
Organization: Royal Institute of Theoretical Theology

In article <[e-mail]>,
 Jens Alfke <[e-mail]> wrote:

>Hmm, you mentioned this once before in private e-mail. To do scrolling you
>just use two frames; it's really almost exactly the way it works in MacApp
>with a scroller view embedding the view to be scrolled. There is a new recipe
>that describes how to do scrolling, which I can e-mail you.

Why wasn't that on the a6 source CD?

Indeed, the way I looked at it, you had to get at the root
view to install your scrollbar there, and that didn't really
work very well with embedding. There were also printing problems,
but I can live with them (who wants a scrollbar on their printout? :-)

>Really, is this the main objection you have to OpenDoc? These things can seem

No; it's the easiest objection. I could go on about what compiling
in CFront/MPW does to my productivity, but I won't :-)
There's also this undefined thing called memory layout. What if
you want to know how much memory you have to play with for
caching issues, or want to do your own "virtual memory" by
purging blocks to disk? There's no supported way of finding
this out; you just have to assume your component will have
"enough" for some default.

>And, back to the theme of this thread, the OpenDoc Parts Framework will take
>care of the grungy details of scrolling for you.

Any year now.

We were expected to talk about starting commercial part development
in the June Munic kitchen, when SOM wasn't there, embedding was a
black art, CFront was the only useable tool, ...
NO WAY! I think OpenDoc is a good idea, but it has to stabilize at
least SOMEWHAT, and the tools mess has to be sorted out before I
can spend time on business on it.

Cheers,

                    / h+

--
  Jon Wdtte
  Hagagatan 1
  113 48 Stockholm
  Sweden


+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 25 Jul 1994 07:11:30 GMT
Organization: The Royal Institute of Technology

In <30u5jq$[e-mail]> [e-mail] (Damir Smitlener) writes:

>looked at TransSkel, PowerPlant, etc. Compared even to Visual BASIC
>they _suck_.

Visual Basic is not in the same cathegory as PowerPlant or TCL.
Visual Basic is in the same cathegory as HyperCard 2.2 (which does
AppleScript as well)

>Until there is something like Visual C++ (if there is and i havent
>seen it, please tell me! and i dont mean multi-thousand dollar
>packages.), ile leave 'Mac' programming to those who want it.

Why not pay a few thousand dollars for a good package? You paid
a lot for you Mac, you're going to earn your living with it, so
you'd better have decent tools, right?

As for a cheap tool, try Symantec C++ 7.0, which comes with an
interface builder (and the Think Class Library version 2.0) which
closely parallells Visual C++.

>All these defenses of mac-programming here confuse me; do you
>folks WANT to work that hard on non-essentials? Doesnt anyone

No; we DON'T work hard on essentials. Either we did it once
before, and copy/paste into a new project, or we use one of the
many good environments/frameworks available. But if you're the
typical lazy integrator consultant type, I'm not surprised you
don't want to do the research necessary before condemning a
platform you haven't used for any extended period of time.

--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --

   What we need is a good GNU [...] licence manager implementation.
                     -- Raphael Manfredi

+++++++++++++++++++++++++++

>From [e-mail] (James F. Amundson)
Date: Mon, 25 Jul 1994 22:51:55 -0600
Organization: Division of Information Technology

In article <[e-mail]>, [e-mail] (John Nagle) wrote:

>         There's also the "Nerdworks" library, which is a free class
> library available on Apple's "ftp.apple.com", and there's a book that
> goes with it.  This is a weak, but workable class library.

Hey! I'm interested in that! The problem is, I've looked all through
"ftp.apple.com" and found nothing. "dir-files-all" had no instances of
"nerd" or "works". Anyone care to point me to it?

Thanks,
Jim Amundson

+++++++++++++++++++++++++++

>From [e-mail] (Herb Poppe)
Date: 26 Jul 1994 15:40:23 GMT
Organization: National Center for Atmospheric Research

In article <[e-mail]>
[e-mail] (James F. Amundson) writes:

> In article <[e-mail]>, [e-mail] (John Nagle) wrote:
>
> >         There's also the "Nerdworks" library, which is a free class
> > library available on Apple's "ftp.apple.com", and there's a book that
> > goes with it.  This is a weak, but workable class library.
>
> Hey! I'm interested in that! The problem is, I've looked all through
> "ftp.apple.com" and found nothing. "dir-files-all" had no instances of
> "nerd" or "works". Anyone care to point me to it?

I couldn't find it either and I looked in directories other than /dts;
e.g., /pub. Is the "book that goes with it" in paper or electronic
form?


Herb Poppe             National Center for Atmospheric Research (NCAR)
[e-mail]   P.O. Box 3000
[phone]         Boulder, CO  80307  USA

+++++++++++++++++++++++++++

>From [e-mail] (John Purlia)
Date: 26 Jul 1994 17:09:26 GMT
Organization: Qualcomm, Inc.

In article <30voj2$[e-mail]>, [e-mail] (Jon Wdtte)
wrote:

> In <30u5jq$[e-mail]> [e-mail] (Damir
Smitlener) writes:
> >All these defenses of mac-programming here confuse me; do you
> >folks WANT to work that hard on non-essentials? Doesnt anyone
>
> No; we DON'T work hard on essentials. Either we did it once
> before, and copy/paste into a new project, or we use one of the
> many good environments/frameworks available. But if you're the
> typical lazy integrator consultant type, I'm not surprised you
> don't want to do the research necessary before condemning a
> platform you haven't used for any extended period of time.

Exactly!!  I have a standard "John's Generic App" I use to start off just
about every project I begin.  All the standard event handling code is
there for handling menus, updates, clicks, idle time, etc...  I wrote it
once and it takes all of a couple hours to plug in specifics for a new
project.  The time is spent doing it right the first time and I believe
EVERY Mac programmer should go through this exercise in order to comprhend
what goes on "behind the scenes".

Why?

Because this basic understanding is essential if you ever want to take
your applications beyond the basic elements provided by a framework.  What
if you need to implement some special user interface element not provided
by the framework, or want to be extra nice to your users and manage
updates within your windows by carefully considering how regions are
validated and invalidated so as to reduce unnecessary (read, ugly)
redrawing?  You'll be much better equipped to produce extra functionality
and refinement in your app's if you've taken the time -- once -- to build
your own basic application.  Toss in a liberal dose of attention to
c.s.m.p, develop, Inside Mac, Tech Notes and sample code snippets, and the
rest is cut'n'paste.

-- John

...........................................................................
John Purlia          : My brain; not my company's brain.  My brain says...
[e-mail] :
Applelink    AM0470  :   "Newton could never live on Via de la Valle,
NewtonMail:  JPurlia :  but it would be right at home on Cruel Lucille"

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 26 Jul 1994 22:07:34 GMT
Organization: Apple Computer

 Jon W!tte, [e-mail] writes:
> Why wasn't that [recipe] on the a6 source CD?

I said it was new! Joshua just finished writing it a few weeks ago.

> No; it's the easiest objection. I could go on about what compiling
> in CFront/MPW does to my productivity, but I won't :-)

We've switched to CodeWarrior/PPC for our development (although scpp should
still work.) Will that make you happy? ;-) Really, I hate MPW just as much as
you do, if not more.

> There's also this undefined thing called memory layout. What if
> you want to know how much memory you have to play with for
> caching issues

Well, that's really an issue with any memory scheme that doesn't fit you into
a predeclared partition size, i.e. almost any memory manager other than the
normal Mac one. Yes, it's a slightly different world. But the user will
appreciate not having to set partition sizes, esp. not for every individual
document! And it would really be infeasible to know how much memory any
particular document needed...
  Your part is free to use the Mac memory manager, by the way, as long as it
allocates stuff in temp memory.

> NO WAY! I think OpenDoc is a good idea, but it has to stabilize at
> least SOMEWHAT, and the tools mess has to be sorted out before I
> can spend time on business on it.

Well, that's the difference between alpha and beta. Alpha tends to be messier
and more unstable. On the other hand, if you start developing with alpha
software, you have more time to learn how the stuff works and more time to
write code. It's a trade-off anyone has to make. I hope you'll try out the
beta release when it ships (nope, I'm not allowed to make any statements
about schedule...)

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Tue, 26 Jul 1994 21:12:04 GMT
Organization: The Information Workshop

>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> Jens Alfke wrote:
>>
>> And, the OpenDoc Parts Framework will take
>> care of the grungy details of scrolling for you.
>>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Jon W!tte writes:
>
> Any year now.
>
> We were expected to talk about starting commercial part development
> in the June Munic kitchen, when SOM wasn't there, embedding was a
> black art, CFront was the only useable tool, ...
>
> NO WAY! I think OpenDoc is a good idea, but it has to stabilize at
> least SOMEWHAT, and the tools mess has to be sorted out before I
> can spend time on business on it.
>

Jon,

>From your point of view, it seems you feel the OpenDoc team has made some
big mistakes.

>From my point of view, which is simply "one other point of view", I have
a high regard for the tough and appropriate choices the OpenDoc team has
made.

Who's perspective is the more accurate one?


- --- The Answer

There IS a problem here, and it has a symptom, and it has a cause.

The SYMPTOM is the the inaccurate perception of something.

The CAUSE is the non-regard for the way in which information is handled.


- -- Pervasiveness

Jon, you are not to blame for your inaccurate assessment of the OpenDoc
development.

You, along with all the rest of us, are not provided with the properly
sequenced information needed so that we CAN form an accurate perception,
or develop the skills to utilize that knowledge in an appropriate amount
of time.

And "OpenDoc" is no different than any other software subject.


- -- A Metaphor

It's almost as though all the "bits of knowledge" are just dropped into a
pile in the middle of the room, and if we REALLY want to participate, it
is up to us to just dive in and sort it all out.

But wait!  If I really want to be accurate here...

... I must add that many, if not most, of those pieces only exist for a
short period of time, and disappear before you have a chance to grab 'em.

But that's okay. Fresh batches of new DIFFERENT pieces are continuously
dumped into that pile.

To be more accurate still...

... there isn't just one pile, but there are at least 12 (at last count).
 Do you have access to all those piles?  You could spend a week chasing a
bug that was solved in one of those piles that you missed!

    Are we programmers, or must we be "pile-masters" as well?


- -- Action Items

The PROBLEM is so huge it is like an epidemic of cancer.

The SOLUTION is easily attainable.

We can't ignore this anymore.



Mark Hanrek
The Information Workshop

+++++++++++++++++++++++++++

>From [e-mail] (Ross Brown)
Date: Wed, 27 Jul 1994 11:37:27 -0400
Organization: Bell-Northern Research

In article <[e-mail]>, Mark Hanrek <[e-mail]> wrote:

>     Are we programmers, or must we be "pile-masters" as well?

Apple's APIculture has turned us all into coder bees!  ;-)

--
Ross Brown
Macintosh/UNIX Systems Integration
Bell-Northern Research Ltd.
[e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 27 Jul 1994 21:13:03 GMT
Organization: Apple Computer

Mark Hanrek, [e-mail] writes:
> You, along with all the rest of us, are not provided with the properly
> sequenced information needed so that we CAN form an accurate perception,
> or develop the skills to utilize that knowledge in an appropriate amount
> of time.

In all seriousness I'd like to ask what we [the OpenDoc team] could do
better. You have the architecture description, you have (preliminary) API
documentation and recipes, you have sample code, you have hours of WWDC
videos, you even have the full source code to all of OpenDoc. There is also a
mailing list (OpenDoc-Interest) where one can ask questions, which usually
get answered by the engineering team.
  Keep in mind that what you have is an _alpha_ release and is quite
preliminary. The documentation isn't really there yet, but Tech Pubs is in
high gear right now putting it together. The beta release will be better
documented; if you find that the effort needed to understand the alpha
release is not worth the benefit in early use of the software, then you can
wait for the beta release.

> The PROBLEM is so huge it is like an epidemic of cancer.
> The SOLUTION is easily attainable.

You titled this section "Action Items" but didn't provide any. If the
solution is easily attainable, what is it?? Again, I'm not being sarcastic...

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

---------------------------

>From Ned Mantei <[e-mail]>
Subject: What does "reentrant" mean?
Date: 19 Jul 1994 10:12:51 GMT
Organization: Neurobiology, ETH-Zurich

In view of the recent thread on "reentrancy and the Power Mac runtime
model", I would appreciate an explanation of the term "reentrant".
Thanks.
Ned Mantei
Dept. of Neurobiology , Swiss Federal Institute of Technology
CH-8093 Zurich, Switzerland

+++++++++++++++++++++++++++

>From [e-mail] (Dana Cartwright 3rd)
Date: 19 Jul 1994 11:22:35 GMT
Organization: Syracuse University, Syracuse NY, USA

Ned Mantei ([e-mail]) wrote:
: In view of the recent thread on "reentrancy and the Power Mac runtime
: model", I would appreciate an explanation of the term "reentrant".

Well, conceptually it's simple, although in practice it gets a bit more
complex.  "Reentrant" simply means "software which does not modify itself".
But read on....

Originally, computer software was NOT reentrant.  John von Neuman,
inventor of the "von Neuman" computer from which all modern computers
are descended, indeed thought that the essence of a computer was that
it could modify its own software on the fly, that is, to be a computer
meant that it *had* to have the capability of having self-modifying
code.

And the world bought into this notion.  It took DECADES to realize
that he was wrong (on this one point--he was a great man, but he
slipped slighly on this point).

Modern programmers who only write application software may find the
concept of "reentrant" a bit puzzling; if you write in C and don't
do tricky things, you automatically and painlessly get reentrant
code.  Ditto all other languages above assembler.

But what get you in trouble are "store to memory" operations which
go directly to a fixed memory location.  For example, on the Mac,
all those lousy low-memory globals violate re-entrancy, if you
write to them.

What's the point of all this?  Well, reentrant software has the
property that you can (a) in effect run multiple copies of the
software without actually having multiple copies sitting around;
all the "copies" can execute from a single master copy (since
it's read-only, everyone can read from the same copy), and
(b) pre-emptive multi-tasking ONLY works with reentrant code.

OK, I'm tired of typing....there is much more which could be said,
but that's the gist of it.


+++++++++++++++++++++++++++

>From [e-mail] (Gavin Eadie)
Date: Tue, 19 Jul 1994 10:32:44 -0400
Organization: University of Michigan

In article <30gd1r$[e-mail]>, [e-mail] (Dana
Cartwright 3rd) wrote:

> Ned Mantei ([e-mail]) wrote:
> : In view of the recent thread on "reentrancy and the Power Mac runtime
> : model", I would appreciate an explanation of the term "reentrant".
>
> Well, conceptually it's simple, although in practice it gets a bit more
> complex.  "Reentrant" simply means "software which does not modify itself".
> But read on....
>
   Strictly speaking, this is misleading because "software which does not
modify itself" is not necessarily reentrant.  The word 'reentrant' is the
clue - it is software which can be 'entered' again and again.  Imagine,
for example, a subroutine which performs some action and it is called by
some application.  While that subroutine is halfway done, and interrupt is
taken and the interrupt processing code also calls the subroutine.  For
this to cause no trouble the subroutine must be reentrant.  It's true that
if the subroutine modified itself this would, probably, cause trouble
(though self modification is possible in reentrant code if you're
careful); it's also the case that if the routine modified global
variables, that would cause trouble too.  But the real definition is only
that the routine can be entered multiple times 'simultaniously' and still
perform desired actions ... Gav

--
Gavin Eadie // U of Michigan Information Systems

+++++++++++++++++++++++++++

>From [e-mail] (Paul DuBois)
Date: 19 Jul 1994 11:33:00 -0500
Organization: Castra Parvulorum

>From article <30g8v3$[e-mail]>, by Ned Mantei <[e-mail]>:
> In view of the recent thread on "reentrancy and the Power Mac runtime
> model", I would appreciate an explanation of the term "reentrant".

It means you can use it twice before it crashes.
--
Paul DuBois
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Tue, 19 Jul 1994 15:14:10 -0500
Organization: University of Illinois at Urbana-Champaign

Dana's article is almost completely wrong.

In article <30gd1r$[e-mail]>, [e-mail] (Dana
Cartwright 3rd) wrote:

>Well, conceptually it's simple, although in practice it gets a bit more
>complex.  "Reentrant" simply means "software which does not modify itself".

No, reentrant only means "able to start execution while already executing
in another context". There can be self-modifying code that is reentrant,
and there can be non-reentrant code that is not self modifying. The
characterization that Dana presents is completely false.

>Originally, computer software was NOT reentrant.  John von Neuman
>[...]indeed thought that the essence of a computer was that
>it could modify its own software on the fly, that is, to be a computer
>meant that it *had* to have the capability of having self-modifying
>code.

Universal Turing machines are self-modifying. I don't thing von Neuman
came up with that. The key to a von Neuman machine is that *code is in
memory*.

>And the world bought into this notion.  It took DECADES to realize
>that he was wrong...

No! Do you think that every program should be in ROM?? The code of a
Macintosh is modified *every time* you open an application. Loading new
code into memory is modifying code. This is *EXACTLY* what we want
computers to do. Using pure ROM for code is completely outdated. There are
certain parts of code that we often don't want modified and so take
troubles to put in memory that is treated as temporarily unmodifiable, but
the world has not thought any the less of von Neuman machines in this
regard.

>Modern programmers who only write application software may find the
>concept of "reentrant" a bit puzzling; if you write in C and don't
>do tricky things, you automatically and painlessly get reentrant
>code.  Ditto all other languages above assembler.

Wrong again. Use the Time Manager on the Macintosh. Use the Device Manager
with completion routines. Then go and write some results to some memory in
a pointer which you allocated in your main loop. Now you are not reentrant
and you haven't done anything particularly "tricky". The key to reentrancy
is that you need to make sure your code can be called from somewhere else
even if it is already in the middle of running.

>But what get you in trouble are "store to memory" operations which
>go directly to a fixed memory location.  For example, on the Mac,
>all those lousy low-memory globals violate re-entrancy, if you
>write to them.

It's not just low-memory globals. It's any constant memory location that
your program has access to.

>What's the point of all this?  Well, reentrant software has the
>property that you can (a) in effect run multiple copies of the
>software without actually having multiple copies sitting around;
>all the "copies" can execute from a single master copy (since
>it's read-only, everyone can read from the same copy

Again, being read-only doesn't make it reentrant.

>(b) pre-emptive multi-tasking ONLY works with reentrant code.

That's simply false. The operating system can perfectly well deal with
code that is not itself reentrant in a pre-emptive multi-tasking
environment.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Doctoral Student - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Marc Cooperman)
Date: 20 Jul 1994 01:41:37 GMT
Organization: Jumpstart Technologies, Inc.

The practical definition:

"re-entrant" routines can be called again and again from unforseen
places in your code, at unforseen times, and they won't break, like all
that other C code you've written

If you program linearly (you can trace a single execution path through your
code that does not double back on itself) you don't have to worry much
about
this

if you program event driven code (like, on a Mac, you know...) that's got
a million disgusting permutations to how it can run, you may have
"re-entrancy" problems, although it is possible to write safe code by
accident

A general rule - a re-entrant procedure should operate on its own copies of
data (automatic variables) wherever possible. If you must change a value
passed in by reference, you probably want to lock the code, to prevent it
from re-entering, before the changes are complete. Either that, or hold the
caller responsible for providing memory to store results and ensuring
proper calling sequence - never write to global variables within the
library!

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Wed, 20 Jul 1994 16:00:47 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Dana Cartwright 3rd) writes:
>Ned Mantei ([e-mail]) wrote:
>: In view of the recent thread on "reentrancy and the Power Mac runtime
>: model", I would appreciate an explanation of the term "reentrant".

>Originally, computer software was NOT reentrant.  John von Neuman,
>inventor of the "von Neuman" computer from which all modern computers
>are descended, indeed thought that the essence of a computer was that
>it could modify its own software on the fly, that is, to be a computer
>meant that it *had* to have the capability of having self-modifying
>code.
>
>And the world bought into this notion.  It took DECADES to realize
>that he was wrong (on this one point--he was a great man, but he
>slipped slighly on this point).

       No, the "B-box", the first index register, was invented in
Britain in the mid-50s.  Before index registers, the only way to
subscript an array was to store into the address part of instructions.
Once index registers were invented, most of the need to modify code
during execution went away.

       Once index registers were invented, the big remaining problem
was storing subroutine return points.  Using a stack fixed that one,
along with providing a separate set of local variables for each
invocation of a function.

       In C-type languages, functions that have no static variables
are generally reentrant.  It's sharing of resources between separate
invocations of the same function that breaks reentrancy.

                    John Nagle

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 20 Jul 1994 19:51:52 GMT
Organization: Apple Computer

Ned Mantei, [e-mail] writes:
> In view of the recent thread on "reentrancy and the Power Mac runtime
> model", I would appreciate an explanation of the term "reentrant".

"Re-entrant" means a call to a subroutine that is already executing. A
recursive call would be the most straightforward example. This could include
indirect recursion where A calls B, B calls C, and C calls A. You can also
get re-entrancy if a routine triggeredy by an interrupt calls a function that
was already executing when the interrupt occurred, or if a process-switch
happens while the function is executing and the next process to run also
calls that function.

Most of the Mac OS and Toolbox routines are not re-entrant; that is, they
will not work properly when called re-entrantly. This is why you can't call
Memory Manager routines from an interrupt (you might have interrupted a MM
routine, so the heap structures might be in an inconsistent state.) It's also
why you can't have multiple Standard File dialogs open at the same time (the
Std File package uses several low-memory globals, and two instances of it
would fight over those globals.)

This is one of the major things that has to be fixed with the OS for the
Copland and Gershwin releases.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Mark Miller)
Date: 24 Jul 1994 17:21:36 -0600
Organization: University of Utah Computer Center, Salt Lake City, Ut.

In article <30gd1r$[e-mail]>,
Dana Cartwright 3rd <[e-mail]> wrote:
>Ned Mantei ([e-mail]) wrote:
>: In view of the recent thread on "reentrancy and the Power Mac runtime
>: model", I would appreciate an explanation of the term "reentrant".
>
>Well, conceptually it's simple, although in practice it gets a bit more
>complex.  "Reentrant" simply means "software which does not modify itself".
>But read on....
>

For a program to be reentrant, it must satisfy one of the following
three conditions:

1. Use no global variables
2. Be programmed VERY carefully to account for a small number of shared
   globals.
3. Be used with a linker / loader that creates a new global data segment
   for each instance of the program running.  Allowing each instance to
   use its own segment either requires referencing all global variables
   from a register base (A5?) or having different address spaces for each
   instance with an MMU.

Other than these conditions, and not using self-modifying code, reentrant
programs may do anything else that is legal under a multitasking
environment, including accessing shared system globals, as long as proper
resource locking and task switching procedures are followed.

  - Mark.

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 25 Jul 94 17:33:19 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <30gd1r$[e-mail]>, [e-mail] (Dana Cartwright 3rd) writes:
>
> Originally, computer software was NOT reentrant.  John von Neuman,
> inventor of the "von Neuman" computer from which all modern computers
> are descended, indeed thought that the essence of a computer was that
> it could modify its own software on the fly, that is, to be a computer
> meant that it *had* to have the capability of having self-modifying
> code.
>
> And the world bought into this notion.  It took DECADES to realize
> that he was wrong (on this one point--he was a great man, but he
> slipped slighly on this point).

No, he wasn't wrong. What happened is that certain people have chosen to
misunderstand the essence of his idea. "Self-modifying" code conjures up
visions of nasty low-level assembly hacks, and, yes, I've seen a few in my time.
But a better concept is "generating code at run-time". As soon as you put
it this way, you start to see that there isn't anything inherently evil about
it. It's a neat technique, quite easy to use in a controlled way from a high-
level language, and on the Mac in particular, it solves a whole class of very
fiddly problems (passing data to callback/completion routines etc) in one
stroke.

Lawrence
driving on the left of the Information Superhighway

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 25 Jul 94 17:47:07 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <30ut20$[e-mail]>, [e-mail] (Mark Miller) writes:
>
> For a program to be reentrant, it must satisfy one of the following
> three conditions:
>
> 1. Use no global variables

And what, pray tell, are the CPU registers, if not global variables?

> 2. Be programmed VERY carefully to account for a small number of shared
>    globals.

Ah, you contradict point 1, which is just as well. The operative word is not
"small". The operative word is "consistency". Consider the entire RAM of your
machine. Consider the entire file system on your hard disk. These constitute
large collections of global data, being operated on by dozens, nay, hundreds
of concurrent processes running in your machine all at the same time. How do
you think they avoid stuffing each other up? There are various techniques in
use:

* Demarcation of responsibility. Not every process needs access to every bit
of data at the same time.
* Interlocks for those cases where two processes _do_ need access to the same
bit of data at the same time.

By obeying a few carefully-chosen conventions, you can manage reentrant access
to an arbitrarily large amount of shared global data.

> 3. Be used with a linker / loader that creates a new global data segment
>    for each instance of the program running.  Allowing each instance to
>    use its own segment either requires referencing all global variables
>    from a register base (A5?) or having different address spaces for each
>    instance with an MMU.

There is an alternative approach, typified by VAX/VMS. Most code under VMS
is reentrant. This particularly includes shared libraries. User programs can
have any number of shared libraries linked into them, and a library can't
depend on occupying the same address space in one program invocation as in
another. The VAX has no base registers, like A5 on the Mac, or like I understand
the PowerPC architecture has. So all that's guaranteed is that each library
maps into its own contiguous section of memory space. Its code and data are
adjacent to each other, so providing all intra-library references use relative
addressing, things continue to work.

Of course, inter-library references are a different matter. This is handled
by adding a "fixup" section to the library: all code references to other
libraries go indirect via the fixup section, and there is also a table of
references within library data structures which need fixing up.

Lawrence
chuffing along the Information Railroad (if you think that's less cool than
tooling along the Information Superhighway, just wait until the next level
crossing).

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Tue, 26 Jul 1994 11:20:05 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:

>No, he wasn't wrong. What happened is that certain people have chosen to
>misunderstand the essence of his idea. "Self-modifying" code conjures up
>visions of nasty low-level assembly hacks, and, yes, I've seen a few in my
>time.

Hey, I've perpertrated a few "nasty low-level assembly hacks" in my time (:
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  But the nastiest one ever was the self-modifying Pascal under CP/M (:

---------------------------

End of C.S.M.P. Digest
**********************